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-<version>.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/<id>/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/<id>/log | one live session's events as JSONL |
GET /thoughtdag/api/sessions/<id>/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/<id>/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/<id>/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/<id>/followup | `{ text |
GET /thoughtdag/api/roots · GET /thoughtdag/api/roots/<key>/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 (<provider>/<model> 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 |
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 <dir>
- 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 <path | url | arxiv:id> | 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
