dsh

dsh-thoughtdag

This directory is the DeepSeek Harness plugin of ThoughtDAG, published to npm as dsh-thoughtdag; its version follows the app's, and the ThoughtDAG build it embeds is the one in this tree.

ThoughtDAG for DeepSeek Harness: open DSH sessions (live or on disk) as editable thought graphs on ThoughtDAG's infinite canvas — from inside the harness UI.

Source, releases and issues live at github.com/chenxiachan/thoughtdag. If the plugin helps you, a star there helps others find it.

This is a DeepSeek Harness plugin (a Cordis plugin distributed as an npm package), built on the same shell pattern as dsh-synapse: the host half mounts the ThoughtDAG SPA under /thoughtdag/ on the EXISTING harness web server (no second process, no second port), and the client half adds a ThoughtDAG entry to the harness sidebar (beside Plugins) that shows the canvas in the main column, in a same-origin iframe.

The entry is the host's own panel mechanism (sidebar.panellist plus the

root main panel slot), so it is there before any session is open and

follows the host's language and theme. The iframe stays in the plugin's own

layer, laid over the panel while it is selected, so switching never reloads

the canvas. (0.4.19 to 0.5.18 floated a 对话 | 思维图 switch over the top

strip instead; every placement collided with host chrome somewhere, see

#55, #61, #63, #73. Hosts without the panel slot still get that switch.)

What works

• dsh plugin --profile web add dsh-thoughtdag installs the plugin from npm; every GitHub release also carries dsh-thoughtdag-.tgz, and the same command takes that file's URL (dsh plugin forwards to pnpm)
• The harness sidebar gains a ThoughtDAG entry; selecting it opens ThoughtDAG at

/thoughtdag/ (same origin — no CORS, no second server)

• The host serves the SPA plus a read-only session bridge:

Endpoint · Purpose GET /thoughtdag/api/disksessions · list durable sessions on disk (id, title, cwd from the session header; newest first) GET /thoughtdag/api/disksessions//log · one disk session as JSONL — the exact dialect ThoughtDAG's dsh-session adapter parses, so a past harness session imports like a local file GET /thoughtdag/api/sessions · list live sessions in this process GET /thoughtdag/api/sessions//log · one live session's events as JSONL GET /thoughtdag/api/sessions//turns · turn boundaries (start/end seq, the person's message id) of a live or on-disk session — the fork points a canvas can name POST /thoughtdag/api/sessions//fork · { afterTurn } or { atSeq } → a child session inheriting the prefix through that completed turn (sessionController.fork, so the chat UI lists it) POST /thoughtdag/api/sessions//inject · { text } or { blocks: [{type:'text',text}] } → model-facing context for the next step (agent.inject; no wake; shown in the transcript as injected context from dsh-thoughtdag) POST /thoughtdag/api/sessions//followup · { text · blocks, mode?: 'queue' · 'steer' } → a user prompt through sessionController.prompt, exactly as the composer sends one GET /thoughtdag/api/roots · GET /thoughtdag/api/roots//list\ · head\ · read\ · range · the other agents' session directories on this machine (claude-projects = ~/.claude/projects, codex-sessions = ~/.codex/sessions) with the desktop bridge's file primitives, so Session Atlas inside the harness lists all three sources and mirrors a Claude Code or Codex session as the desktop does; rel never escapes its root GET /thoughtdag/api/models · the harness's model catalog in the SPA's list shape (/ ids, the harness default) POST /thoughtdag/api/stream · POST /thoughtdag/api/claude · the SPA's own proxy protocol, answered on the harness's providers and credentials (ctx.llm.stream); the embedded SPA is built with VITE_API_BASE=/thoughtdag, so its model picker and every canvas-native generation (summaries, condensing, a canvas that is not a mirrored session) run on the harness's models. These calls do not enter a session log; a mirrored session's turns go through /followup harness/agent (a catalog entry) · pick it in the picker and the question goes INTO the harness: a fresh session per call, the canvas's wired context injected first (agent.inject, source dsh-thoughtdag), the question as a user follow-up, the harness's own agent loop with tools; text, reasoning and tool calls stream back as the SPA's frames, the first frame names the session ({ harnessSession }) and, once the question enters the surface, the turn it created ({ harnessTurn: { turn, userMessageId, seq } }), so the canvas can mark its node as that turn's mirror instead of receiving it twice. The session stays in the Chat and the atlas. harness: { cwd } sets the session's working directory (the canvas passes the project it mirrors, else the current chat session's); harness: { session } continues a mirrored session instead of forking a fresh one (a tail follow-up); images (base64) are admitted through the controller's prompt and a vision model is selected for that turn, so a picture the canvas holds is read by the harness's own eyes POST /thoughtdag/api/fetch-url · the SPA's link snapshot ({ url } → { title, text, fetchedAt, html? }) through the harness's bounded, credential-free fetcher (ctx.web.fetch)

Disk logs are zstd *concatenated-frame* files; the bridge locates frame boundaries structurally and decodes each with node:zlib (the same walk the DSH persistence backend performs), so no external zstd binary or native module is needed.

• The bridge is Host-header fenced (localhost/127.0.0.1 + trustedHosts)

Verified (2026-09)

• installed into the local web profile via dsh plugin --profile web add
• a fresh web-profile boot serves /thoughtdag/ (SPA) and the bridge API; the

index injection table lists dsh-thoughtdag/client.js

• headless-browser walk: the ThoughtDAG entry appears in the sidebar, selecting it lays the

same-origin iframe over the main column, and ThoughtDAG boots inside it

• fetching the bridge from INSIDE the thoughtdag origin works with no extra

auth: GET /thoughtdag/api/disksessions lists every on-disk session (new sessions created by the running instance appear automatically) and GET .../log returns the full event stream

• real session logs decode correctly (multi-frame zstd → 15k+ JSONL lines,

identical to the zstd CLI)

• the live bridge (/api/sessions) reflects the running instance's active

session as soon as the GUI opens one (verified: opening the UI surfaces the auto-created session with its live seq), complementing the disk archive

Canvas-side import

When a turn launched from the canvas needs the person's approval (the harness's sandbox asking to escalate, a policy hook answering ask), the plugin answers first: it registers ahead of the harness's own panel on the approval/request waterfall for the sessions it is running, streams the question to the canvas as an approval frame, and the node shows it — tool, command, the harness's reason, allow once or reject. The decision returns through POST /thoughtdag/api/approvals/:id and stays on the node as part of the turn's record. If the canvas stream is gone, the request is handed down the chain to the harness's panel unchanged.

Inside the iframe the canvas runs with this bridge as its session source (the SPA is built with VITE_DSH_BRIDGE=/thoughtdag/api): Session Atlas lists the harness's sessions beside Claude Code's, Codex's and Pi's (served by this host from their directories), opens one as a graph, and follows it live by polling the session's seq. The client half tells the canvas which session the chat shows (td:current-session) and switches the chat when the canvas names one (td:select-session).

The why layer inside the harness

The plugin bundles the thoughtdag CLI's library (lib/why.mjs, built at pack time) and answers the same four questions over the same ~/.thoughtdag index — no CLI or MCP install needed:

Surface · What Native tools · why_check(path), why_file(path, include_read?, limit?), why_find(phrase, in?, limit?), why_recall(session, turn) — the agent calls them like any harness tool; relative paths resolve against the session's working directory /why · a person asks from the chat; the answer is the CLI's why output, no model message System-prompt section · four lines telling the model to why_check before editing a file with history and how to read the other three

Both are on by default; whyTools: false / whyPrompt: false in the plugin config turn them off.

Not yet (roadmap)

• Canvas why panel (a node's file → its history through /thoughtdag/api)
• Canvas UI for the write bridge: name a fork point on a node, hand a compiled context to inject, continue with followup; the client already switches the chat to a session the canvas names (td:select-session)
• replace: shadow a surface range from the canvas (DSH's compaction primitive); needs a live check of how the chat renders a replaced range
• Theme sync of the canvas itself with the harness UI (the sidebar entry already follows the host's language and theme)
• Open the chat's current session on the canvas automatically when the view switches

Development

# 1. build the embedded ThoughtDAG SPA with a /thoughtdag/ subpath base (from the repo root)
npm run dsh:build            # writes dsh/dist-app, which git ignores

# 2. install into a profile from this directory (pnpm link)
dsh plugin --profile web add /abs/path/to/thoughtdag/dsh

# 3. restart the profile's web app; the switch floats at the top of the page

The script drives tsc, vite and esbuild through Node directly, so the same code path builds on Windows, macOS and Linux. Always run it as npm run dsh:build instead of passing the flags through Git Bash by hand: MSYS path conversion rewrites --base=/thoughtdag/ into a Git-install path, which bakes a broken base into dist-app — every asset request then falls through to the SPA fallback HTML and the canvas mounts as a blank white page.

While developing, the profile keeps a pnpm *link* to this directory, so edits to lib/ apply on the next restart without reinstalling.

License: MIT