DeepSeek Harness session sync — continue on any device

Last updated 2026-09-17 · MIT licensed · free for personal self-hosting

DeepSeek Harness (client id dsh) is the most technically unusual agent in the list: its sessions are not plain JSONL but a generationed event log.

Where DSH keeps its sessions

Item Value
Root <DSH_HOME>, defaulting to ~/.dsh
Session path sessions/--<cwd-slug>--/<session-<uuid>>/session.vN.jsonl[.zstd]
Current generation the adapter publishes generation v3 (one zstd frame per line) and freezes an older predecessor beside it
Dependency reads and writes both need zstandard (the install-deps script covers it)

Connecting it

  1. Open the setup help page, pick DeepSeek Harness, and download the client package (server address pre-filled).
  2. On first run, execute install-deps.bat (Windows) or ./install-deps.sh (macOS / Linux) — for DSH this also installs zstandard.
  3. Register with the generated command — your workspace API key is already filled in. The client starts as HERMES_SYNC_AGENT=dsh.
  4. Restart DSH (desktop users: confirm the registration row really took effect, below).

First start pulls incrementally; an empty server gets a full push to complete the pairing; then it syncs every 5 minutes.

The desktop registration trap (worth its own section)

DSH Desktop registers the sync client as a @deepseek-ai/dsh-mcp-client row in cordis.patch.yml (desktop profile: desktop). That row must set cwd to a directory that exists:

  • the plugin's stdio config defaults cwd to "" and hands it straight to spawn(), where Node raises ENOENT;
  • with the default failOnStartupError: false that startup error is swallowed — the desktop boots normally while sync silently never runs (no MCP child process, no mcp__hermes-sync__* tools).

The quick check is the tool list: if the sync tools are missing, cwd is the first suspect. Set the client's unpack directory as cwd; set failOnStartupError: true temporarily if you want the error to surface on the desktop's startup page.

Behaviour worth knowing

  • The sync side owns whole generated logs — header, turn/start / step/start frames and contiguous sequence numbers are produced by the writing side, so a synced session is directly readable by DSH.
  • The workspace domain is bootstrapped by DSH itself from session headers; you do not configure it.
  • Do not hand-edit these files — break the integrity of a generationed log and DSH refuses to read it as a session.

Across devices, across agents

Two machines connected to one workspace share the sessions/ tree, so a long reasoning run can be continued on the other machine or handed to another agent — all through the same pool.