Introduction¶
DSH (DeepSeek Harness) follows the philosophy that “everything is a plugin.” The Agent runs on the local machine to handle code, files, and various automation tasks. The problem is that these tasks often do not finish in a few seconds: running a round of tests or batch-processing a group of files requires watching the terminal to see progress; if the Agent requests permission confirmation during the work, a person must also be present.
Connecting back through SSH or remote desktop solves the “can operate” problem, but the experience is fragmented—typing commands on a small screen and scrolling through conversations is not as natural as in an everyday chat.
The @lanbaolu/dsh-wechat-bridge plugin introduced below takes a different path: it integrates WeChat into DSH. After scanning a QR code to bind a personal WeChat account, you can chat with the local Agent in WeChat, send and receive files, receive task notifications, and complete permission approvals.
Plugin Overview¶
This plugin is maintained by lanbaolu, is currently at version 0.9.0, and is released under the MIT license. The WeChat protocol layer is ported from wechat-claude-code (iLink Bot protocol); on the DSH side it is implemented as a Host plugin and provides two management entry points: Model tools (available in CLI/Headless) and a Web management panel (available in Web/desktop).
Cross-platform: Windows / macOS / Linux daemons all use pure Node.js process management and do not depend on launchd / systemd / Windows Service.
The overall chain is: the bridge daemon handles the WeChat protocol, communicates with the DSH Host Plugin over HTTP + SSE that listens only on 127.0.0.1 and uses random token authentication, and the plugin then creates or resumes a DSH Agent.
微信 App ←→ iLink Bot API ←→ bridge daemon (Node.js)
│ HTTP + SSE (127.0.0.1, token 鉴权)
▼
DSH Host Plugin
│ ctx.agents.create/resume + followup
▼
DSH Agent (本机 LLM + 工具)
The repository code is divided into three parts: src/bridge/ contains the WeChat protocol layer and bridge daemon, src/index.ts contains the DSH Host plugin (internal API, Agent lifecycle, daemon management, model tools), and src/client/index.ts contains the Web management panel (registered through the settings.section slot).
The following sections detail the features.
Conversation and Session Continuity¶
After scanning the WeChat QR code to bind a personal WeChat account, you can directly chat with the local DSH Agent in WeChat. Each WeChat account corresponds to one DSH session. After the DSH Host restarts, it automatically resumes the original persisted session, so context is not interrupted; slash commands such as /clear, /new, /stop, /cwd, /model, and /prompt can be used inside WeChat. See below for the full list.
Streaming Replies, Timeout Reassurance, and Anti-Blocking¶
The DSH Agent’s assistant/chunk output is pushed to WeChat through local SSE, batched and aggregated before sending, so long replies do not flood the chat.
When DSH has no output for more than 5 minutes, the bridge automatically sends a “still processing” message so that you do not think it is stuck. This behavior is configurable; see “Timeout Reassurance” later.
For anti-blocking, the bridge automatically injects a channel constraint prompt into the WeChat session: it disables browser-side interactive option tools (which are invisible on phones and can block forever) and switches to plain-text numbered options instead.
Proactive Notifications and Approvals in WeChat¶
The Agent can use the wechat_notify tool to proactively push messages to WeChat when a task completes, fails, or needs confirmation. Notifications have built-in throttling: at most 6 per hour and 50 per day. Excess messages are queued and sent later to avoid personal-account risk-control issues.
When the Agent requests permission, the bridge pushes an approval message to WeChat: reply /yes to approve or /no to deny. Timeouts are automatically denied (fail-closed). Only the bound account owner can make the decision, and this does not affect desktop GUI sessions.
Two-Way Files and Media¶
Media send/receive capabilities (as of version 0.9.0):
| Direction | Text | Image | Voice | File | Video |
|---|---|---|---|---|---|
| WeChat → DSH | Supported | Supported; CDN download, decryption, and writing to disk | Supported; transcribed into text | Supported; downloaded to disk and passed to the Agent | Supported; CDN download and writing to disk, then passed to the Agent |
| DSH → WeChat | Supported; batched and aggregated before sending | Supported; routed directly by file extension | Not supported | Supported; replies that mention it trigger automatic push | Supported; routed directly by file extension (mp4/mov/webm/mkv/avi) |
Two additional notes:
- Video send/receive was completed on 2026-08-29, and real-device send/receive spot checks were completed on 2026-08-30.
- Voice outbound (DSH → WeChat) is not yet supported because there is no public reference implementation of the protocol.
In addition, local files mentioned in DSH replies are automatically sent back to WeChat, and you can also send images or files directly to DSH from WeChat.
Message Queue and Multi-User¶
Normal messages received while a task is processing are queued and processed after the current task finishes. In multi-user scenarios, queues are independent per user, so user A’s long task does not block user B.
Multi-user support is based on a trust set plus per-user sessions: each trusted user has an independent DSH session, context, message queue, and approval ownership, invisible to other users. The trust set is controllable and can be revoked. See the “Security Model” section for details.
Installation and Enablement¶
Installation¶
Three installation methods are available; choose one.
Method 1: one-command npm installation (recommended):
npm install @lanbaolu/dsh-wechat-bridge
dsh plugin --profile web add @lanbaolu/dsh-wechat-bridge
dsh web
The first command installs the package, the second registers the plugin into the DSH web profile, and the third starts the Web interface.
Method 2: local path installation (development / personal use):
git clone https://github.com/lanbaolu/dsh-wechat-bridge.git
dsh plugin --profile web add /path/to/dsh-wechat-bridge
dsh web
In development mode, you can also use the super injector:
dev_inject_plugin /path/to/dsh-wechat-bridge
Method 3: run from source:
npm install
npm run build
npm run build:client
npm run typecheck
Runtime requirement: Node.js >= 18; note that the build:client script uses tsdown and requires Node.js 22.18+ or 24.11+ (CI verifies with 22/24).
QR Binding and Startup¶
It is recommended to complete this in the DSH Web settings page:
- Open Settings and go to the “WeChat Bridge” block.
- Enter the DSH working directory.
- Click “Scan to Bind” and scan the QR code on the page with WeChat.
- After binding succeeds, click “Start”.
You can also run this in the terminal on the machine where DSH is installed:
node lib/bridge/main.js setup
Follow the prompts to scan with WeChat, then select the DSH working directory when finished.
Daemon Management¶
Starting, stopping, restarting, checking status, and viewing logs for the daemon are all managed by the DSH plugin, via two paths:
- Model tools: instruct the model in the DSH conversation to execute
wechat_bridge_start,wechat_bridge_status,wechat_bridge_logs, orwechat_bridge_stop; - Web panel: in the “WeChat Bridge” block on the settings page, click Start / Stop / Restart.
After completing the steps above, the channel between WeChat and DSH is connected, and daily operations can be completed in WeChat.
Common WeChat Commands¶
| Command | Description |
|---|---|
/help |
Show help |
/clear |
Clear the current DSH session |
/new |
Start a new session (equivalent to /clear) |
/stop |
Stop the current task and clear queued messages |
/status |
View session status |
/cwd [path] |
View / change the working directory |
/model [name] |
View / change the model |
/prompt [content] |
View / set the system prompt |
/history [count] |
View recent conversations |
/send <path> |
Send a local file to WeChat |
/trust <userId> [note] |
Add a trusted user (manual mode; owner only) |
/distrust <userId> |
Revoke a trusted user (owner only) |
/trustlist |
View the trust set (owner only) |
/trustmode [mode] |
View / switch trust mode (owner-only / bootstrap / manual) |
Optional Configuration¶
The default plugin data directory is ~/.dsh/wechat-bridge/, which can be adjusted with the DSH_HOME environment variable. The following two settings are edited in config.json under that directory.
Timeout Reassurance¶
When DSH produces no output for a long time, the bridge proactively sends a “still processing” message (by default, this is triggered after 5 minutes of silence). If this feels too frequent or you want custom wording, edit the calm section in config.json:
{
"calm": {
"enabled": true, // 是否启用安抚,默认 true
"silenceMs": 600000, // 首次静默多久后安抚(毫秒),默认 300000(5 分钟)
"intervalMs": 900000, // 两次安抚最小间隔(毫秒),默认同 silenceMs
"maxCount": 3, // 每轮任务最多安抚次数,0/省略 = 不限制
"messages": [ // 自定义文案(随机取一条),留空用内置默认
"还在处理中,这个问题有点复杂,请再稍等一下",
"马上就好,正在收尾"
]
}
}
Changes take effect immediately after saving (up to a few seconds of delay); the daemon does not need to be restarted. You can also adjust this in the “Timeout Reassurance” block of the Web panel.
Prevent Sleep¶
Disabled by default. When enabled, the daemon suppresses system sleep while running—locking the screen or closing the laptop lid does not suspend the session, and WeChat messages continue to be handled. This is suitable for running long unattended tasks. Edit config.json:
{
"preventSleep": true
}
You can also use the “Prevent Sleep” switch in the Web panel. After changing it, restart the daemon for it to take effect; click “Restart” in the panel. Platform implementations: macOS uses caffeinate, Linux uses systemd-inhibit, and Windows uses SetThreadExecutionState, all on a best-effort basis.
Security Model¶
First, make a premise clear: QR-code binding under the iLink protocol is the bot’s own login (not pairing with a user), so the “multi-user” boundary is defined above the protocol layer—trusted WeChat users’ from_user_id values are added to a trust set, and inbound messages are allowed or rejected accordingly.
There are three trust modes, with fail-closed as the default:
| Mode | Behavior | Suitable for |
|---|---|---|
owner-only (default) |
Only the bound account owner is recognized; strangers are always rejected | Single user |
bootstrap |
The first stranger to contact automatically enters the trust set (one-time), then no further automatic additions | Quick setup / trial |
manual |
Only users explicitly added by the owner via /trust or the Web panel can chat |
Formal multi-user use |
Several supplementary rules:
- Stranger messages are only logged, not replied to, and do not leak internal information. Optionally set
notifyRejected: trueso the owner receives a “stranger attempted contact” reminder. - The trust set is persisted in
trust.json(permissions0600), andmodeis the single source of truth. - After revocation via
/distrustor the panel, the user’s new messages are immediately rejected; their historical session files are retained read-only, so history is not lost.
For isolation, each trusted user (including the owner) has an independent set: a DSH session (keyed by ${botAccountId}::${userId}), session files, message queue, context token, and the effective scope of /history, /status, /cwd, and /model. User A’s /yes or /no only adjudicates pending approvals for A’s own Agent; user B has no authority to decide on A’s behalf.
The verification status must be stated honestly: real-device verification of the multi-user path (bootstrap trust-set entry, dual-user isolation, and concurrent operation) has not yet been completed and still requires a second WeChat account walkthrough. Until then, enable bootstrap / manual modes only in controlled environments.
For credential security: the internal API between the daemon and the DSH plugin listens only on 127.0.0.1 and uses random token authentication; WeChat account credentials are stored only locally in ~/.dsh/wechat-bridge/accounts/, with permissions 0600; tokens / secrets / passwords in logs are automatically masked.
Suitable Scenarios and Notes¶
Suitable for the following scenarios:
- You need to leave long-running tasks unattended, step away from the computer, and still receive progress updates and handle approvals as needed;
- You want to use personal WeChat as a lightweight control entry point alongside the CLI and Web panel to manage DSH sessions;
- Multiple people share one bot and need independent sessions and approval boundaries for each person (note the multi-user verification status above).
Before using it, keep the following in mind:
- The project disclaimer states that it is intended only for personal learning and automation. Using non-official WeChat protocols carries account risk; users must assess the risk themselves and bear the consequences.
- Voice outbound is not yet supported. Real-device verification of the multi-user path is still pending, so use
bootstrap/manualmodes in controlled environments first. - The plugin runs with the permissions of the current
dshprocess. Before installing, review the source code and license (this project uses MIT).
Conclusion¶
Overall, this plugin connects WeChat to DSH’s conversation, notification, and approval flows. Installation, binding, startup, and configuration all have clear command and panel entry points, the daemon is uniformly managed by the DSH plugin, and the plugin works across three platforms. If you also need to reach your local Agent while away from the machine, you can try it using the “Installation and Enablement” section above.
- Community catalog page: https://www.skillhub.cn/plugins/lanbaolu/dsh-wechat-bridge
- GitHub repository: https://github.com/lanbaolu/dsh-wechat-bridge