Dsh Any Agent

🧪 0.6.2 offline suite green · 👀 new live call-chain view (watch / dashboard, with token usage) · 🔌 MCP over stdio · 📦 Zero dependencies · 📜 MIT

An MCP server that drives DeepSeek Harness as a long-lived coding agent. Hand it a goal, let it write code and run scripts, steer it mid-flight, and collect the result when you are ready.

Claude Code · Claude Desktop · Codex · Cursor · Windsurf · Zed · Gemini CLI · opencode · VS Code — or any client that speaks MCP over stdio.

🎯 The problem this solves

You already have a coding agent in your editor. What you do not have is one that can:

• hand a multi-hour job to another agent and walk away — then collect the result when it's done;
• keep the job alive across restarts of your editor, your session, your machine's idle reap;
• cut in mid-flight when it's going the wrong way, without destroying the work;
• run several of them at once and switch between them;
• see what it is doing without asking the agent — which tools it called, which approvals went through, how many tokens it spent.

DSH (DeepSeek Harness) can do all of that — it has file/shell tools, skills, subagents and workflows — but it is a GUI-first application. Its own sdk profile exposes only 3 requests and can't resume, cancel, or answer approvals.

This server is the missing adapter: it makes DSH into a well-behaved background agent that any MCP client can hire, supervise and collect from.

Think of it as &job — like & in a shell, but for an agent.

✨ Why it's different

🧭 Positioning: a dispatcher, not a capability aggregator

This server dispatches; it does not re-implement what DSH already does. The caller gives a goal, and DSH decides which tools, skills, subagents or team to use. Nothing from DSH's tool surface is proxied, duplicated or preloaded.

Dispatch on demand: dsh_send passes a goal, not a tool manifest, and the caller does not need to know DSH's tool list. The DSH agent picks what it needs — including capabilities added after this server was built (for example the experimental Agent Teams). This server does not grow one MCP tool per DSH feature.

Team mode (opt-in since 0.5.0): off by default. Run dsh-any-agent team on and reconnect; the profile switches to dsh-team (the experimental Agent Teams packages), and dsh_send then adds a short "form a team if this needs parallel or multi-role work" line; simple tasks are not forced into a team. Turn it off with dsh-any-agent team off, or for one call with dsh_send(team=false). The team profile disables the legacy subagent tools and replaces them with nine team tools; teammates share one workspace.

Only dispatch semantics become tools: start, send, read, get, review, interject, interrupt, approve, queue, inbox, status, release, takeover, doctor. No file I/O, no shell, no editor, no task board.

When to add something outside DSH: only when you need a guarantee rather than a behavior — for example, several top-level sessions editing the same repository need outer worktree isolation. For collaboration, prefer letting DSH run the team itself (mount the experimental team packages into the profile; teammates share one workspace).

Quick start

Requires Node.js ≥ 22.15 and DSH installed with a working model route and credentials. See Requirements for details.

npm install -g dsh-any-agentdsh-any-agent-setupdsh-any-agent-setup --yes

The second command previews the changes; --yes applies them. Reconnect your client's MCP server, then ask your agent to start a DSH conversation in your project, dispatch a task, and collect the result. The dispatch workflow shows the tool sequence.

Want to see it first? Watch the 54-second promo — dispatch, interject, the sentinel landing and the caller's review, with the terminal replayed from a real run:

[▶ Play the dsh-any-agent promo (54 seconds)]

Before your first task: read the Usage Notes, especially the model-config and external-MCP permission boundaries. External MCP tools bypass DSH's sandbox. For a fresh machine, follow the migration guide.

🧰 Tools

👀 Live view: see what the dispatched work is doing

The tools above are for the calling agent. You, sitting at the client, usually see one dsh_send and nothing else. Since 0.6.1 the server writes each conversation's activity to a local event stream, so you can watch the call chain without going through the agent:

claude-code  pid 8328└─ e896d16a  temperature module  running · total 278k/17k · context 3%   ├─ ✓ run-…-1  [send] · done · 1m24s · 8 tools · 69k↑ 4.1k↓ tok   └─ ▶ run-…-2  [queue] · running · 156k↑ 12k↓ tok         ✓ read   temp.js                  13ms         ✓ edit   temp.js                  18ms         ◆ approval auto-allow ⚠ danger-full-access  node --test         ▶ pwsh   node --test

dsh-any-agent watch

dsh-any-agent dashboard --open

• watch: the call chain in your terminal, redrawn in place like top (no scrolling spam). watch <conversation id prefix> follows one conversation; --once prints once and exits.
• dashboard: a local read-only web page; --open launches it in your default browser. Left: conversations grouped by client. Middle: the run timeline, with a timing bar per tool call and approvals/escalations highlighted. Right: overview, tool breakdown, files touched, approvals, and token usage (input / output / cache hit, context window, per-turn chart).
• English / 中文: follows your system language by default; pass --lang en|zh to choose, or switch from the page's top-right corner.
• Doesn't disturb running work: both are separate processes that only read event files — they never touch the write lock or DSH. Use them to watch progress, and don't open MCP-driven conversations in the DSH GUI (that takes the write lock; see usage notes 3.10).
• Safety and privacy: the dashboard binds 127.0.0.1 only, its URL carries a one-time token, it checks the Host header, and it has no control that changes state. Command, path and prompt previews are redacted first; reasoning is never written at any level. DSH_MCP_LIVE=meta keeps only tool names and status; off disables it.

Details in Usage · side view; event format and design trade-offs in the live view design.

📚 Documentation map

🧑‍🤝‍🧑 Team mode (opt-in)

Off by default. Run dsh-any-agent team on and reconnect; the profile switches to dsh-team (the experimental Agent Teams packages) and dsh_send adds a short "form a team when this needs parallel or multi-role work" line. Simple tasks are not forced into a team. Turn it off with dsh-any-agent team off, or for one call with dsh_send(team=false).

Full steps (commands, verification, rollback) are in Team mode.

Star History