dsh-plugin-qq-bridge
Bridge an official QQ bot to DeepSeek Harness (DSH) — in-process.
A message in QQ starts (or resumes) a real DSH session inside the host process. The session shows up
in the desktop app's sidebar, can be opened and continued there, and the answer goes back to QQ as text,
image or file. QQ is just one more input/output for a normal DSH session.
How it works
| Separate bridge process | This plugin |
|---|
| Task execution | spawns dsh --profile qq --json | ctx.agents.create() / resume() inside the host |
| Where sessions live | only in that CLI profile | the host's own session store (visible in the GUI) |
| Permissions | env vars on the child process | per-session permission preset |
| Lifetime | you keep start-bridge.cmd running | lives as long as the DSH host |
The QQ protocol layer (token, gateway, passive-reply budget, chunking, workspaces, chat history) is shared
with the standalone bridge; only the execution side is different.
Requirements
- A DSH host that provides the
agents, agentDefaultModel, agentPresets, permissionPresets,
sessionTitle and workspaceRegistry services (the desktop app does).
- A QQ official bot application (AppID + AppSecret) with the message intents you plan to use enabled
(C2C, group @-message, …) on the QQ open platform.
Install
dsh plugin add github:tbb051122/dsh-plugin-qq-bridge
Then restart the DSH host — host-side plugin code is only loaded at startup.
Configure
Config lives at <DSH_HOME>/qq-bridge/config.json (~/.dsh/qq-bridge/config.json by default).
Set QQ_BRIDGE_HOME to point the whole plugin at another directory (handy for testing).
A minimal config:
{
"appId": "your-app-id",
"appSecret": "your-app-secret",
"intents": 33554432,
"defaultCwd": "",
"allow": { "users": [], "groups": [] }
}
See config.example.json for every key.
Keys that matter for the plugin:
| Key | Meaning |
|---|
appId, appSecret | QQ bot credentials (from the QQ open platform). |
sandbox | Use the QQ sandbox environment instead of production. |
intents | Message subscription bitmask; 33554432 is C2C messages, add the group bit for group chats. |
defaultCwd | Working directory for new sessions. Point it at a registered DSH workspace to have QQ sessions appear there; leave empty for an isolated directory per session. |
agentPreset | Agent preset name; empty means the host default. |
permissionPreset | danger-full-access (default, unattended), workspace-write or read-only. |
attachWorkspace | When defaultCwd is a registered workspace, attach the session to it so the GUI shows it. |
allow.users / allow.groups | OpenID allow-lists. Empty means "locked": use /bind <code> with bindCode to pair. |
maxConcurrent, queueLimit | How many agent runs at once, how many conversations may queue. |
passiveWindowMs | The passive-reply window QQ gives you after a user message. |
taskTimeoutMs | Per-task timeout. |
selfTestOnBoot | Run one end-to-end self test on first boot and post the result to QQ. |
titlePrefix | Session title prefix (default QQ). |
Commands (sent in QQ)
/help, /id, /bind <code>, /new, /status, /stop,
/ws (list workspaces), /ws <name|index>, /ws 0 (back to the default directory),
/history [n].
Files
Everything the plugin writes lives under <QQ_BRIDGE_HOME> (default <DSH_HOME>/qq-bridge):
config.json, state.json (session map, allow-lists), history/ (per session and workspace),
workspaces/ (workspace link index), tasks/ (default task root) and logs/.
Security note
The default permissionPreset is danger-full-access so an unattended QQ task can actually do its job.
Set it to workspace-write or read-only if the bot is reachable by anyone you do not trust, and keep
allow.users limited to people you know.
Development
node lib/cli.mjs --mock --once "hello" # full pipeline with a fake runner and fake QQ
node lib/cli.mjs --selftest # config / workspace / runner checks
Set QQ_BRIDGE_HOME to a scratch directory so the mock run does not touch real data.
License
MIT
