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