FlashingChen/dsh-worktree
Codex-style permanent git worktrees for DeepSeek Harness: worktree_create/list/remove agent tools, a /worktree
dsh-worktree gives DeepSeek Harness the same durable-worktree workflow as codex worktree create --permanent: a permanent worktree is a real git worktree add --detach checkout that survives sessions and restarts — you (or the agent) create it once, and any later session can be opened inside it to keep working where the previous one left off, without ever touching your main working tree. The model itself gets the tools, so it can fork its own permanent workspace mid-task: create a worktree at a specific commit, work there with the normal file tools, and clean up afterwards. CLI parity with Codex: worktree_create ↔ codex worktree create --permanent, worktree_list ↔ codex worktree list, /worktree open registers the worktree as a DSH workspace, worktree_remove ↔ codex worktree close/delete, plus a one-shot context note when a session runs inside a registered worktree.
Install
dsh plugin --profile web add dsh-worktreenpm package dsh-worktree 0.1.0 (registry-verified 2026-08-24). Install: dsh plugin --profile web add dsh-worktree, restart DSH. Gives a DSH profile Codex-style permanent git worktrees: the agent gets worktree_create / worktree_list / worktree_remove tools and you get /worktree create|list|open|remove slash commands. Clone alternative: git clone https://github.com/FlashingChen/dsh-worktree.git && npm install (self-contained deps pinned to harness versions). MIT.
Compatibility
DeepSeek Harness web profile (Cordis plugin). Worktrees live at <repo-root>/.dsh-worktrees/<name> — the same hidden-directory pattern as Codex's .codex/worktrees/ — so they stay inside the repository (and, when the session workspace is the repo root, inside the session's workspace-write sandbox). Every worktree is recorded in a per-repository manifest (<repo-root>/.dsh-worktrees/manifest.json: name, path, base commit, created-at, creator session), which is what makes worktrees permanent — they survive DSH restarts, are listed by the tools/commands, and are recognized when a new session opens inside one. Creating a worktree also registers it in ctx.workspaceRegistry so it appears in the DSH workspace list.
Details
- Repo: FlashingChen/dsh-worktree
- Category: Coding & Development
- Stars: 6
- Version: npm package dsh-worktree 0.1.0 (registry-verified 2026-08-24)
- Last push: 2026-08-13
- First seen: 2026-08-13
Recent updates
The current English README documents: the Codex-to-dsh-worktree command/tool parity table, how it works (worktree location, manifest.json permanence, workspaceRegistry registration), and install (dsh plugin add or clone + npm install).
FAQ
- What makes a worktree permanent?
- Every worktree is recorded in <repo-root>/.dsh-worktrees/manifest.json (name, path, base commit, created-at, creator session), so it survives DSH restarts, is listed by the tools/commands, and is recognized when a new session opens inside it.
- Can the agent create worktrees itself?
- Yes — the model gets worktree_create / worktree_list / worktree_remove tools, so it can fork its own permanent workspace mid-task and clean up afterwards.
- Where do worktrees live?
- At <repo-root>/.dsh-worktrees/<name>, inside the repository (and inside the session's workspace-write sandbox when the workspace is the repo root).
Alternatives
wloops/dsh-git-worktree · yangyongzhen/dsh-git-workflow · WhitePlusMS/dsh-git-graph