Introduction¶

When doing agent collaboration in DSH (DeepSeek Harness), a common pain point is “it claims it made changes” without evidence: when an agent executes a task, the conversation only contains its own self-report. The actual changes, which files were modified, and whether it went off-track all require manual inspection of the workspace. The cost of troubleshooting is mainly spent on “fact-checking” rather than the task itself.

The plugin introduced in this article, dsh-codebuddy-bridge (package name lunatic-eclipse/dsh-codebuddy-bridge), addresses this step: it connects the locally installed CodeBuddy CLI to DeepSeek Harness. DSH dispatches tasks, the engine executes them, and results are injected back into the dialogue. It then uses the pre-change backups left by the CLI itself to perform content diffs, providing PASS/FAIL and evidence. Maintainer: lunatic-eclipse, version 0.3.2, MIT license. This project comes from the community and has no official affiliation with DeepSeek / Huafang.

What is it¶

In short: a DSH plugin that connects the local CodeBuddy CLI (the same engine built into the WorkBuddy desktop version) to form a closed loop of “Dispatch → Execute → Result Injection → Verification Round by Round”. The engine built into the WorkBuddy desktop version is exactly this one, so once WorkBuddy is installed, it can be used directly.

It fills the final link in collaboration. Most “two-agent collaboration” currently stops at producing self-reports; this plugin builds verification on file facts and CLI session logs, rather than on textual outputs.

Core Features¶

The plugin provides a set of workbuddy_* tools. The tool names follow workbuddy_* because they interface with the local WorkBuddy/CodeBuddy engine; the package name wasn’t changed along with it, avoiding breaking old documentation and habits.

| Tool | Function |

| — | — |

| workbuddy_relay(prompt, edit?, mode?) | Replaces /codebuddy; injects results back into the dialogue; requires the dsh-connect-workbuddy plugin; mode="plan" is for read-only planning |

| workbuddy_review(path, focus?, maxFindings?) | Read-only review of a file: fixed template + automatic check if it was read or written |

| workbuddy_verify(run?, session?) | Verifies if a round made changes: PASS/FAIL/WARN + evidence; does not consume quota |

| workbuddy_usage(days?) | Read-only usage report: rounds in the last N days, duration (by day/mode), tokens per round; does not consume quota |

| workbuddy_read(turns?, session?) | Reads the WorkBuddy desktop’s own session logs |

| workbuddy_status() / workbuddy_close() | Status and session management |

| workbuddy_dispatch(task) + /dsh-handoff | Legacy file handoff fallback channel |

Two modes are worth mentioning separately:

• Audit (workbuddy_review): Checks for errors, outputs “Location — Issue — Fix”, up to N items, max 200 words per item.
• Plan (workbuddy_relay(mode="plan")): For thinking clearly, outputs conclusions / constraints / assumptions / candidate routes / counter-examples for each route / suggestions; read-only, unlimited length, conclusions saved to plans\<timestamp>.md in the exchange directory.

Quota strategy: relay and review share 6 rounds per session per hour. If exceeded, it directly returns { rejected: true, retryAfterSec } without calling the CLI or consuming quota; verify / read / status only read local files and do not occupy quota.

Installation and Usage¶

Execute the official installation command in DSH:

dsh plugin --profile web add dsh-codebuddy-bridge

If not yet published to npm, install from the repo:

dsh plugin --profile web add github:<owner>/<repo>

After installation, restart DSH. A “CodeBuddy Collaboration” capsule will appear below the input box.

Prerequisites: Windows (engine path is auto-detected based on WorkBuddy installation location, other platforms untested); WorkBuddy desktop installed (comes with CodeBuddy CLI) or self-installed @tencent-ai/codebuddy-code. The dsh-connect-workbuddy plugin is optional: the /codebuddy relay route is provided by it; without it, other functions still work.

The declared total dependencies are listed below for easy environment confirmation:

peerDependencies:
  dsh-connect-workbuddy  >=5.0.0 (optional: /codebuddy relay route provided by it, missing means only other functions available)
  react                 ^18.2.0

engines:
  node  ^22.19.0 || >=24.0.0
  dsh   >=0.2.0-rc.1 <0.3.0-0

Typical Usage¶

After installation, the built-in process of the plugin can proceed as follows.

1. Open the capsule below the input box. It is independent per session; when closed, tools will be taken from that session’s agent scope.
2. Tell the model “Let CodeBuddy change X”, and the model will call workbuddy_relay(prompt, edit: true).
3. The result is injected back into the dialogue as a message; the panel above the input box lists each step (Read / Modify / Execute).
4. Say “Verify”, and the model calls workbuddy_verify() to get PASS/FAIL + evidence.

This verification step does not consume quota because it reads the CLI’s own session logs and pre-change backups to perform content diffs, without extra calls to the engine.

Configuration is in cordis.patch.yml or plugin settings:

| Field | Default | Description |

| — | — | — |

| collabDir | ~/.dsh/codebuddy-bridge | Exchange directory: round logs, mode switches, reports |

| permissionMode | dontAsk | Passed to engine: read allowed, write rejected, never wait; file editing requires explicit enabling (e.g., workbuddy_task passes acceptEdits, relay adds --edit); bypassPermissions for full allowance |

| cliPath | Auto-detect | CodeBuddy CLI entry point, only default path on Windows |

| productConfig | Auto-detect | Makes the entry work as WorkBuddy |

| model | Engine default | Passes --model |

| timeoutMs | 900000 | Single round timeout |

| watchMs | 3000 | Polling interval for the fallback channel |

| roundLimit | 6 | Maximum rounds per session per window (relay + review shared) |

| roundWindowMs | 3600000 | Window length; calculated from the first round counted, non-sliding |

Permissions and Privacy¶

The plugin’s declared read/write scope is as follows; it is best to confirm against your own workspace before use.

• Read: ~/.codebuddy/projects/<slug>/<session>.jsonl (CLI’s own session logs, used to generate the panel and verify evidence), and ~/.workbuddy/projects (only read by workbuddy_read).
• Write: Several jsonl/md files under collabDir (including limits.json for the quota ledger, plans\ for plan conclusions); the engine itself writes workspace files according to permissionMode.
• No touch: Account tokens, login state files, any network requests (networking only happens inside the CodeBuddy CLI).

Note: The panel needs to display details, so the “tool call argument summary” of the session logs will enter DSH’s dialogue context. Sensitive workspaces should evaluate for themselves whether this applies.

The plugin runs with the permissions of the current DSH process; therefore, you should check the source code and license (MIT) before authorizing.

Applicable Scenarios and Notes¶

Suitable for the following situations:

• In DSH, you need to call the local CodeBuddy CLI / WorkBuddy engine and want to inject the change results back into the dialogue as evidence.
• You want to use a “one agent does the work, another agent reviews/accepts” workflow, where humans are only responsible for the final decision and a final glance.
• You want to limit execution rounds per session to avoid failed retries consuming quota.

At the same time, be aware of these limitations:

• Only one CodeBuddy session can run at a time.
• The panel is not in the right sidebar (third-party plugins cannot open that position), but is placed above the input box.
• There is no “running” real-time progress, only details after completion.
• workbuddy_verify can only verify actions + file facts; if it says the right thing but didn’t do it, or if it did something but didn’t say so, they will be marked out; the final judgment still requires human effort.
• Throttling is counted by DSH session: restarting does not reset it, opening a new session does; the fixed window is at the junction of two windows, theoretically allowing nearly 2x the nominal value within one hour.
• The conclusions of plan mode only guarantee “complete disk persistence”; whether they are correct still requires human judgment.

Development and Self-testing:

node --check index.js
node --check client.js
npm test        # node:test, covers verify decision branches

Modifying index.js only requires toggling the plugin on/off in plugin management; modifying client.js requires restarting DSH, as the client module is only scanned at startup.

Conclusion¶

The value of dsh-codebuddy-bridge is to replace “it claims it made changes” with “has diff, has evidence, can give PASS/FAIL”. It does not handle authentication and does not consume extra quota; it is suitable for developers who want to retain a verifiable CodeBuddy collaboration channel in DSH; however, it only verifies actions and file facts, and the final judgment remains with the human.

Directory page: https://www.skillhub.cn/plugins/lunatic-eclipse/dsh-codebuddy-bridge
Repo: https://github.com/lunatic-eclipse/dsh-codebuddy-bridge