The project's README from github.com/ZSeven-W/dsh-crew. As one markdown file: README.md.
A DeepSeek Harness plugin: dispatch work to DSH agents from Claude Code / Codex / Antigravity / Grok, without giving up the host's native subagent UI.
Native Progress UI • Tier Policy & Escalation • Dispatch Guardrails • Jobs Board • In-Host DSH Sessions • Vision & Image Gen (Native-First) • One-Click Install
npm: @zseven-w/dsh-crew · Current plugin release: 0.1.0-rc.4 · Tested with DSH 0.1.1-rc.1
English · 简体中文 · 繁體中文 · 日本語 · 한국어 · Français · Español · Deutsch · Português · Русский · हिन्दी · Türkçe · ไทย · Tiếng Việt · Bahasa Indonesia
The DSH Crew settings page — host integrations, dispatch policy, execution and the multimodal bridge
DSH Crew is a plugin for DeepSeek Harness (DSH) — an open-source agent harness. It makes DSH agents dispatchable from Claude Code, Codex, Antigravity and Grok: the orchestrator keeps its own model, the work runs on a real DSH agent with that harness's tools, sandbox, presets and session history, and the host still shows it as a native subagent with live progress.
What runs the work is a DSH agent, not a bare model call. Tiers (flash / pro) select how much capability that agent gets from the harness's configured roster — DeepSeek V4 Flash and V4 Pro today — so a change of model in DSH needs no change here.
🧵 Native Progress UIWorkers appear as regular subagents in Claude Code / Codex / Antigravity / Grok — dispatch count, running step, tool calls and token usage all show up in the host's own task panel, plus a claude-hud statusline segment: |
🎚️ Tier Policy and Escalation
|
🏛️ In-Host DSH SessionsWith the bundle installed in a DSH profile, each worker is a first-class DSH session: visible in the Web UI, grouped by working directory, mounted with the Agent preset you choose per tier. Without DSH running, dispatch falls back to a standalone DSH runtime, so CI and headless environments still work. |
👁️ Vision and Image GenerationDSH's models are text-only. |
🛡️ Dispatch GuardrailsEvery dispatch is checked before anything spawns. Worker→worker nesting is capped at origin-chain depth 3 and cycles are refused; a second worker on a workspace another job already holds is refused with the holder's info — never silently queued. Refusals are readable errors: wait or re-scope, don't bypass. |
📋 Jobs BoardThe DSH Crew panel doubles as a jobs board: every worker job — running or finished — is listed with tier, effort, live progress and tokens, held workspaces show their holders, and a job that vanishes mid-flight (e.g. a hub restart) is surfaced as an orphan ghost instead of disappearing silently. |
🔌 Custom ProvidersBring your own endpoint (Base URL + API key + models) or a local command template. Each provider has a connectivity test that checks reachability and auth, then makes one real vision call so you find out now, not mid-task. |
📦 One-Click InstallThe settings page installs and updates the Claude Code plugin, the Codex role files and the Antigravity / Grok agents, skills and commands for you — marketplace registration, permission allowlist, HUD wiring, absolute paths rendered for this machine — and restores them just as easily. Every settings file is backed up first. |
Claude Code / Codex / Antigravity / Grok (orchestrator, keeps its own model)
└─ ds-flash / ds-pro ← native subagent shell (progress shows in the host's task UI)
└─ MCP: dsh_run_worker(tier, effort, cwd, worker=)
├─ worker="agy"/"grok" → that external CLI runs the task (explicit opt-in)
├─ hub reachable → session inside DSH (visible in the Web UI, grouped by cwd)
└─ otherwise → dsh-jsonrpc-agent runtime (worker.cordis.yml)
└─ DeepSeek V4 Flash / Pro (DSH SDK, event stream → progress and token stats)
Dispatch fans out. Below, eighteen workers translate this README in parallel: the host counts them as its own subagents, while the harness runs them as real sessions.
Claude Code sees dsh-crew workers as native subagents, with a statusline segment tracking running tiers, elapsed time and tokens.
The DSH Crew panel sees the same run from the harness side: which host dispatched each job, its tier and effort, live progress and token usage.
The panel is also the jobs board: running and finished jobs stay listed with tier, progress and tokens, held workspaces name their holders, and a job that vanishes mid-flight (a hub restart) surfaces as an orphan ghost instead of disappearing silently.
Install into a DSH profile from npm:
dsh plugin --profile web add @zseven-w/dsh-crew@latest
dsh web
Or, for local development straight from the source tree:
dsh plugin --profile web add link:/path/to/dsh-crew
dsh web
The link: protocol symlinks the profile dependency to this repository, so rebuilds are visible immediately.
In hub mode — the installation above — workers run inside the DSH instance and use the DeepSeek credentials it is already configured with. Nothing else to set up.
Only the standalone fallback needs a key of its own: dispatching from a host with no DSH instance running launches a worker runtime as a separate process. Obtain an API key from platform.deepseek.com and write it to ~/.config/dsh-crew/.env:
DEEPSEEK_API_KEY=sk-...
node scripts/smoke.mjs
The smoke test dispatches one cheap job through whichever path is available — the hub when a DSH instance is running, standalone otherwise — and prints which one it used. Within about ten seconds you should see smoke test passed — configuration OK. On failure the reason is printed, scoped to the path that was tested.
Then open Settings → DSH Crew and install the host integrations — Claude Code, Codex, Antigravity, Grok — with one click, or drive the same installer from the command line:
node src/install/cli.mjs claude # Claude Code plugin: marketplace + permissions + HUD segment
node src/install/cli.mjs codex # Codex agents + prompts
node src/install/cli.mjs agy # Antigravity MCP config + agents + skills
node src/install/cli.mjs grok # Grok MCP config + agents + commands
node src/install/cli.mjs all # all four hosts at once
# uninstall symmetrically (uninstall-claude | uninstall-codex | uninstall-agy | uninstall-grok):
node src/install/cli.mjs uninstall-claude
flash is fast and cheap (simple tasks), pro reasons harder (complex problems). Today they map to DeepSeek V4 Flash and V4 Pro; swap models in DSH and nothing changes here.off = no reasoning, high = high reasoning investment, max = maximum reasoning investment.One-click installation (choose one):
node src/install/cli.mjs allBoth do the same thing: register local marketplace (the repo itself, via .claude-plugin/marketplace.json) + claude plugin install + MCP tool permission allowlist + claude-hud worker status segment config (auto-backup settings.json before changes, idempotent). Restart the session after installation for changes to take effect.
⚙dsh 1▶pro 2m14s 21.7k/606 ✓3 (current tier / elapsed time / token usage / completion count)statusline/statusline.sh or statusline/worker-segment.sh can be independently integratedMCP_TOOL_TIMEOUT adjustable), long tasks can have orchestrator use dsh_spawn_worker + dsh_worker_result(wait_seconds) pollingclaude --plugin-dir /path/to/dsh-crew to temporarily loadThese override the global defaults for the current session only, and are enforced at the tool layer rather than by prompting:
| Command | What it does |
|---|---|
/dsh-crew:config |
Show or set this session's defaults: tier=flash|pro, effort=off|high|max, mode=auto|hub|standalone, timeout=<seconds>, policy=auto|flash-only|pro-only, escalate=true|false, reset |
/dsh-crew:on · /dsh-crew:off |
Turn dispatch for this session on or off (off is a hard switch: the tool refuses) |
/dsh-crew:status |
Live status of worker jobs: tier, progress, tokens, current tool |
/dsh-crew:playbook |
Dispatch best practices: choosing flash vs pro, self-contained briefs, parallelism, verifying results, guardrails |
Recommended to use the installer (auto-renders paths for this machine, copies the /dsh-config, /dsh-status and /dsh-playbook prompts):
node src/install/cli.mjs codex
Or manually copy (requires manual path modification after copying):
cp codex/agents/*.toml ~/.codex/agents/ # global or project-level .codex/agents/
Role files come pre-configured with:
default_tools_approval_mode = "approve" (required, otherwise tool calls are auto-cancelled in exec mode)tool_timeout_sec = 3600Note: When manually copying, absolute paths in the args field must be updated to match actual installation location; the installer handles this automatically.
codex exec mode can also directly call dsh_run_workerThree prompts are installed for Codex:
| Command | What it does |
|---|---|
/dsh-config |
Show or set this session's defaults: tier=flash|pro, effort=off|high|max, mode=auto|hub|standalone, timeout=<seconds>, policy=auto|flash-only|pro-only, escalate=true|false, reset |
/dsh-status |
Live status of worker jobs: tier, progress, tokens, current tool |
/dsh-playbook |
Dispatch best practices: choosing flash vs pro, self-contained briefs, parallelism, verifying results, guardrails |
node src/install/cli.mjs agy
Registers the dsh-crew MCP server in ~/.gemini/config/mcp_config.json and installs the ds-flash / ds-pro agents plus the dsh-config, dsh-status and dsh-playbook skills into ~/.gemini/config/ (all files backed up first). Restart the session after installation.
ds-flash or ds-pro as the agent to dispatch tasksdsh_worker_config reads or overrides the session defaults| Skill | What it does |
|---|---|
/dsh-config |
Show or set this session's defaults (tier / effort / mode / timeout / policy / escalation / reset) |
/dsh-status |
Live status of worker jobs: tier, progress, tokens, current tool |
/dsh-playbook |
Dispatch best practices: choosing flash vs pro, self-contained briefs, parallelism, verifying results, guardrails |
--dangerously-skip-permissions + accept-edits): agy 1.1.16 has no workspace-scoped permission mode, so a headless worker must auto-approve tool requests.Uninstall: node src/install/cli.mjs uninstall-agy
node src/install/cli.mjs grok
Writes the [mcp_servers.dsh-crew] section into ~/.grok/config.toml and installs the ds-flash / ds-pro agents plus the /dsh-config, /dsh-status and /dsh-playbook commands into ~/.grok/ (all files backed up first).
ds-flash or ds-pro as the agent to dispatch tasks| Command | What it does |
|---|---|
/dsh-config |
Show or set this session's defaults (tier / effort / mode / timeout / policy / escalation / reset) |
/dsh-status |
Live status of worker jobs: tier, progress, tokens, current tool |
/dsh-playbook |
Dispatch best practices: choosing flash vs pro, self-contained briefs, parallelism, verifying results, guardrails |
grok mcp doctor reports "folder untrusted"); a global install is unaffected — change directory or pass --trust.bypassPermissions (always-approve, as the grok docs recommend for headless automation); deny rules and hooks still apply.Uninstall: node src/install/cli.mjs uninstall-grok
| Tool | Description |
|---|---|
dsh_run_worker |
Blocking task dispatch (tier: flash/pro, effort: off/high/max, cwd, worker), waits for result |
dsh_spawn_worker |
Async dispatch, returns job id (for parallel fan-out); collect results with dsh_worker_result |
dsh_worker_status |
Real-time progress of all jobs (turn/step/current tool/token) + cwd advisory locks |
dsh_worker_result |
Fetch result, can specify wait_seconds to wait |
dsh_worker_cancel |
Cancel specified job, terminate its runtime process |
dsh_worker_config |
Read/set session defaults (tier, effort, mode, timeout, policy, escalation) and list worker_profiles |
Progress is simultaneously mirrored to ~/.config/dsh-crew/status.d/ (one shard file per writer, can be read by statusline / external monitoring).
Every dispatch is checked before anything spawns — refusals are readable errors, never silent queues:
origin_depth_limit, default 3) is refused, and so is any cycle (the same backend + cwd appearing twice) — the guard that stops recursive worker self-amplification.dsh_worker_cancel, or pass allow_concurrent_cwd: true (read-only tasks only).How to dispatch well — flash vs pro, self-contained briefs, safe parallelism, verifying results, and the guardrails above — is bundled as a per-host playbook: /dsh-crew:playbook (Claude Code skill), /dsh-playbook (Codex prompt, Antigravity skill, Grok command).
worker="agy" / worker="grok" pins a dispatch to that external CLI (backend × model × effort) instead of the DSH tier logic. It is explicit opt-in — there is no default, so set it only when the user asks for that CLI. Caveats: grok refuses to start repo-local MCP servers in untrusted folders, and agy runs workers with full approval (no workspace-scoped permission mode).
DeepSeek is a text-only model and does not support image input or generation. This plugin sources these capabilities externally through MCP tools:
Native vision first: when the vision provider is a built-in CLI (or explicitly native), describe_image first tries DeepSeek's own VL model deepseek-v4-flash-vision-exp (direct API call; key from DEEPSEEK_API_KEY or ~/.config/dsh-crew/.env). Any failure degrades gracefully to the CLI provider chain below, which is kept as the fallback. Image generation is untouched — the native model only ever looks at pictures.
| Tool | Description |
|---|---|
describe_image |
Answer questions by viewing images (screenshots, designs, charts, etc.), results cached by provider + model + image + question |
generate_image |
Generate image from text description, save to specified absolute path; output is flat bitmap (requires OpenPencil for layer editing) |
Session image pasting: In DSH, switch model to DeepSeek (vision) ◉ to directly paste images. Images remain in session and display normally; the plugin appends transcribed text after them and strips images before sending—you see the image, the model reads the text. The transcription follows the same native-first ladder: DeepSeek's VL model when a key is available, then your configured CLI provider.
In DSH settings page → DSH Crew → Multimodal (or directly edit ~/.config/dsh-crew/config.json):
Vision provider (image viewing):
native / deepseek-native (DeepSeek's own VL model — tried first automatically