dsh-baton

• The only difference in the hand-over runs is one line added at the end of the request: 交给 DeepSeek Harness 去做。 ("Hand it to DeepSeek Harness.")
• Same model and effort in both arms, and every run judged by the same acceptance check, which the model never sees.
• Tasks 1 and 2: the mean of three runs per cell. Task 3: one run per cell. Every run passed its acceptance check, with no rework.
• Prices are list prices. DeepSeek is counted at its peak price; the real DeepSeek bill came to about 58% of that.
• The 5-hour window share is worked out from each run's cost: 12.27 points per $1 for GPT-6.1 Sol, 9.90 for GPT-6 Astra.
• 0.6.2 cuts the MCP instructions to one sentence, so Codex reads a few thousand to over ten thousand fewer new input tokens per hand-over. The Codex runs were measured with 0.6.1 to 0.6.3, where a Stop hook did the waiting; from 0.6.4 one dsh_wait call does it, also in one model request for every 59 minutes of a run.

• Claude Code waits for a run in the background (the wait_command that dsh_send returns) and is woken once, when the run ends.
• Codex waits inside dsh_wait. The plugin sets Codex's tool timeout for dsh-baton to an hour (tool_timeout_sec = 3600), so one call waits up to 59 minutes: a run that ends within the hour costs one model request to wait for, however long it takes, and the result comes back as an ordinary tool result in the chat. A longer run returns timed_out with just the state after 59 minutes, and Codex calls again without summarising. Pressing Stop ends the wait at once. Codex gets no wait_command: its terminal cannot wake it, so it would poll. Conversations still open since before the plugin set the timeout, or an entry you wrote yourself without it, wait 270 s per call, just under Codex's default 300 s timeout; after Codex restarts, they get the long wait too. Measured in the Codex desktop app: a 28-minute run took one dsh_wait call; a 62-minute run took two, the first returning timed_out after 59 minutes and the second getting the result 3 minutes later, with no dsh_status calls in between.
• Sessions with a Harness goal. A goal (a message starting with /goal sets one) makes Harness start the next round by itself as soon as a turn ends. A run sent to such a session is waited for until the goal stops, not just its first round, so "hand this to Harness" brings back the finished work; sessions without a goal are waited for as before. When the user asks for progress reports ("report every 10 minutes"), the client passes until turn: it then reports at the end of a round once 10 minutes (every_minutes) have passed since the last report, with every round since. To follow a session without sending anything, the client calls dsh_wait with session_id (Claude Code runs the follow_command in the background instead). Each report carries every round since the last one (the latest round's closing reply (up to 1500 characters), each earlier round as a one-line digest with its tools; any round in full through dsh_read_session), the files changed in the folder since the last report (since the run began, for the first), and the goal's state (phase, rounds started of the most allowed, whether Harness goes on with it), plus a cursor that the next call passes back, so switching between the two modes neither repeats nor misses a round. Both return at once when Harness asks a question (answer it with dsh_answer and session_id) or waits for an approval, when the goal is complete, paused, blocked or cleared, or when Harness will not go on with it by itself (for example after a Harness restart, until you press Continue). In Codex one call follows a goal for at most 15 minutes and Codex then calls again, so a message you type reaches it within that time; such an in-between return carries only the goal's state and how many rounds wait, not their texts.
• Changing the request while it waits. In Codex, send the change with Steer: Codex stops waiting at once, steers it into the same Harness session (dsh_send with mode steer) and waits on the new run; Harness does both in the same turn. Sent with Queue, Codex sees it only when the run ends; you can also press Stop first and then send it. In Claude Code, just send it: it waits in the background, so it steers the change in right away. A steered run ends together with the original and they share one result; a queued run comes back on its own. Runs working in the same folder at the same time are named in each other's results, so neither removes the other's files.

The server's MCP instructions are a single sentence (from 0.6.2); how to hand over, wait and answer is in each tool's own description. Codex repeats the instructions in front of every tool's description, so the catalogue it shows the model is now about 9.7k characters instead of 24.3k.

dsh-baton workspacesdsh-baton new-workspace ~/code/new-app --title "New App"dsh-baton sessions --cwd ~/code/new-appdsh-baton send --cwd ~/code/new-app "Scaffold the project"dsh-baton send --session session-xxxx "Next: add tests"dsh-baton send --session session-xxxx --mode steer "Interjection: don't change the API"dsh-baton wait hrun-xxxx              # blocks, prints the final reply; exit 0 on successdsh-baton status hrun-xxxxdsh-baton follow session-xxxx --until turn --every 10m   # a session's Harness goal: blocks until the next reportdsh-baton activity session-xxxx       # running turn, sub-agents, background jobsdsh-baton cancel --session session-xxxxdsh-baton rename session-xxxx "New title"dsh-baton rename-workspace ~/code/new-app "New name"

(From source, use node src/cli.mjs ….)

When the plugin is unreachable, the MCP server falls back to Harness's dsh headless command. It can only continue sessions it created itself (headless does not load agent presets such as standard), and new sessions do not appear in the desktop sidebar. By default patches/account.patch.yml reuses the desktop app's DeepSeek account sign-in, so no API key is needed.

What the plugin does when switched on. It copies the MCP server to ~/.dsh-baton/app, a folder that stays put, and writes the MCP entry into ~/.claude.json and ~/.codex/config.toml directly, keeping a *.bak-dsh-baton backup of each. It starts the server with your own Node.js ≥ 22.15 when it finds one on PATH; without one, with Harness's own runtime (the Harness app in Node mode, ELECTRON_RUN_AS_NODE=1), so nothing else has to be installed. Either way it works with only the desktop apps installed, when claude / codex are not on your PATH. It runs again on each Harness start: an entry that is already right, or a working one that starts another copy of dsh-baton, is left alone. In Harness, the source switches to the npm registry ("Official npm registry", 「npm 官方源」) by itself once you type the package name, and no restart is needed. To turn the registration off, set DSH_BATON_AUTO_REGISTER=0 for Harness.

Codex's tool timeout. Codex stops an MCP tool call after 300 s unless the server's table sets tool_timeout_sec. The plugin writes tool_timeout_sec = 3600 into [mcp_servers.dsh-baton] in ~/.codex/config.toml, and adds it to an existing table that has none; a value you set yourself is kept. The server reads it and makes each dsh_wait that long less 60 s. Codex reads the setting when it starts or loads a conversation and keeps it: new conversations get it without restarting Codex, and so does every conversation after Codex restarts, while conversations open since before keep Codex's 300 s limit. dsh-baton tells them apart by when the conversation and the Codex process started (~/.dsh-baton/codex-timeout.json holds when the value was written) and keeps their waits at 270 s.

Codex's cwd for dsh-baton. Codex starts an MCP server in the conversation's folder unless its table sets cwd; when that folder is gone (a project on an external drive that is not connected) the server cannot start and the conversation has no dsh_* tools. The plugin writes cwd (your home folder) into [mcp_servers.dsh-baton] and adds it to an existing table that has none; a cwd you set yourself is kept.

Updating to 0.6.4. Nothing to restart, approve or set. Updating the plugin in Harness installs the new server into ~/.dsh-baton/app and writes the timeout; Codex's running server picks up the new version on its next call (it checks for a newer copy before each tools/list and tools/call). New conversations wait up to 59 minutes per call; conversations already open go on as before, with 270 s waits. The Stop hook that plugins 0.6.0 to 0.6.3 added is taken out by itself, together with its trust record; there is nothing to untick in Codex. New conversations, and every conversation after Codex restarts, have no hook at all.

Updates need no restart. When a newer version lands in ~/.dsh-baton/app (a plugin update, setup, or a copy by hand), or the same version with changed files, conversations already open in Claude Code and Codex use it from their next dsh_* call: the server checks the folder before each call, starts the new version, and says once in that call's result that it was updated. A dsh_wait that is already running finishes on the old version first. If the new version cannot start, the old one keeps working and the result says why. A tool added in the new version shows up in Claude Code at once (the server tells the client its tool list changed); Codex keeps the tool list a conversation started with, so it does not show a new tool until the next conversation; it can still use one at once through dsh_call, which the update note points to, and the tools it already has run the new code right away.

npx -y dsh-baton-mcp setup does the same registration from a terminal: for a plugin that could not register, or when you come from an MCP directory. With the plugin already registered it changes nothing, then points you to the plugin if it is missing.

Updating. Harness has an update button only for its official plugins, so: Plugins → dsh-baton-host → Uninstall, then Add plugin → dsh-baton-host. For a while after a release, Harness installs the previous version instead (pnpm's minimumReleaseAge holds back versions published very recently, and the install dialog says so); to get the new one at once, type the version: [email protected]. A pre-release must always be added by its exact version, such as [email protected]: Harness resolves @next to a broken placeholder. Plain dsh-baton-host gets the latest release. Switched on again, the plugin brings the MCP server to the same version; new conversations use it. If the two are ever out of step, the first tool call that notices it says so, naming the older side and the newer side's exact version to install.

Removing. Harness → Plugins → dsh-baton-host → Uninstall, then npx -y dsh-baton-mcp setup --remove. The plugin cannot tell an uninstall from Harness quitting, so it leaves the MCP entries to that command, which also deletes ~/.dsh-baton/app; run records stay in ~/.dsh-baton until you delete it.

Upgrading from dsh-bridge. In Harness, uninstall dsh-bridge-host, then add dsh-baton-host; switched on, it replaces the old dsh-bridge MCP entries. DSH_BRIDGE_* variables and an existing ~/.dsh-bridge folder keep working for now. Tools get a new prefix (mcp__dsh-baton__…), so update any permission allowlists. A plugin added before 0.4 by pasting ~/.dsh-baton/app/host still works but does not update with npm: uninstall it and add dsh-baton-host by name.

From source (to follow main or change the code): git clone https://github.com/JialaoLiu/dsh-baton.git, then in Harness add the plugin from the clone's host folder (Add plugin → paste the path). Switched on, it registers the clone itself, so changes run before they are published. Update with git pull. node dsh-baton/src/cli.mjs setup registers the clone from a terminal.

Windows. Same steps; WINDOWS.md covers what differs (a named pipe instead of a socket file) and fixes for a Plugins page that cannot install or uninstall.

The plugin and setup write the same entries these commands would (with the absolute path of node, since desktop apps start MCP servers without your shell's PATH):

claude mcp add dsh-baton -s user -- "$(command -v node)" "$PWD/dsh-baton/src/server.mjs"codex mcp add dsh-baton -- "$(command -v node)" "$PWD/dsh-baton/src/server.mjs"

-s user matters: without it, Claude Code registers the server for the current project folder only.

Claude desktop app (optional): for the chat app's connectors (separate from Claude Code), add this to ~/Library/Application Support/Claude/claude_desktop_config.json and restart the app. It shows as a "Local dev" connector.

{ "mcpServers": { "dsh-baton": { "command": "/absolute/path/to/node", "args": ["/absolute/path/to/dsh-baton/src/server.mjs"] } } }