dsh-worktable: an agent-project workbench that lives inside DeepSeek Harness

The problem: agent projects have no home in the harness GUI

DeepSeek Harness runs conversations. A user working on several self-hosted projects ends up with a flat list of sessions and no spatial memory of which conversation belongs to which codebase. dsh-worktable addresses that gap by giving each project a folder, an icon, a position in a sidebar drawer, and a bound conversation. Opening the project switches the chat pane to that conversation. The README describes the target user indirectly: people who collect self-hosted projects alongside resident plugins such as dsh-travelatlas, and who want the harness to behave like a workspace rather than a chat log. The second audience is the operator rather than the builder. The control room is described as a built-in default project that mirrors every other project's state, which suggests the plugin is aimed at someone supervising several agent runs at once, not someone writing a single script.

One package, two halves: host routes and an injected client

The architecture section states that a single package ships both a host Cordis plugin and a web client. The host side exposes routes under /api/worktable/* covering health, file system access, git, file read and write, site serving, mkdir, workspaces, and a native skin template. A separate WebSocket endpoint, /api/worktable/term, backs the terminal pane and uses PowerShell on Windows. The client is injected into the sidebar and the shell overlay through what the README calls the slot protocol. The split engine, tab model, drag and drop, and persistence are self-built rather than inherited from the host. This split matters for anyone evaluating maintenance risk: the client is not a thin skin over host components, so a host UI change can affect the plugin even when the API routes are untouched. The plugin type is described as pure additive, with no official plugin replaced, which limits the blast radius of a failed install but does not eliminate it.

The control room mirrors session state without polling or tokens

The control room reads the host session list snapshot, which the README breaks into running, pending and completed states, plus jobs and subagent catalogs. The transport is described as an event-driven host snapshot mirror with zero polling and zero tokens, and the plugin's own summary table calls it a subscription-driven mirror of host session runtime snapshots. The practical consequence is that the card grid reflects what the host already knows rather than asking a model to summarise progress. A three-column grid shows working, needs you, and done, with live runtime, subagent counts and a cleaned message preview. The control room is pinned and undeletable, and it is the first project, which means it cannot be removed from the drawer the way ordinary projects can. That is a deliberate design decision, and it also means the plugin always has at least one project entry even on a fresh install.

Installing from the release tarball or a local clone

The README gives two install paths. The recommended one pulls the latest GitHub Release tarball and needs no Git: dsh plugin --profile web add "https://github.com/Aisland-SJL/dsh-worktable/releases/latest/download/dsh-worktable.tgz". The second is for source work and uses a link: specifier, which the README says accepts a local absolute path only and no spaces in the path: git clone the repository, then dsh plugin --profile web add "link:<absolute path>/01_content", with a Windows example of D:/tools/dsh-worktable/01_content. Either command registers dsh-worktable in the profile bundle list, writes to ~/.dsh, and may ask for authorization. If the dsh binary is missing, the README points to npx @deepseek-ai/dsh. After that you restart the DSH web process, refresh the GUI, open the pinned control-room card, bind one conversation by joining an existing one or creating a new one, and then create projects from the sidebar plus button by picking a layout preset and setting a project folder. For development the build must run inside 01_content, because building from the repository root writes lib/ to the wrong place while the host keeps loading the old bundle.

State lives in localStorage, not in workspace files

The summary table states that state is localStorage only, under the dsh.worktable.* prefix, and that no workspace files are touched. Projects, conversation bindings and layouts therefore live in the browser. The troubleshooting section repeats this as reassurance after a harness update: your data is safe because those three things are in localStorage while project files stay in your own project folders. Two consequences follow. First, clearing browser storage or moving to a different browser profile loses the drawer configuration, including which conversation each project is bound to. Second, the plugin has nothing to migrate on the server side, which is part of why the upgrade story is short. The trade is that there is no export path documented in the material, so a layout you spent time arranging is only as durable as the browser profile holding it.

The window task handshake and its lock

The custom window pane works through a file contract rather than a socket. The README states that the agent writes widget-result.json into the project folder on completion, and the client then mounts the artifact into the addressed window and locks it. The requirement side is sent to a new or existing conversation. This is a simple mechanism, and the lock is the part worth pausing on: once the artifact is mounted, the window is locked, so iterating on a generated widget means going back through the conversation rather than editing in place. The other panes listed are file explorer, terminal, browser, animation site and custom window, with declarative layout presets for a left column, a top row, or a main grid plus a right chat pane. Draggable dividers, per-pane tabs and per-layout width persistence are all client-side concerns handled by the self-built split engine.

Version coupling is the real cost of adoption

The most recent release listed is v0.3.3, dated 2026-09-06, and its title names compatibility with DSH 0.1.2-rc.1 plus a data path fix. Two earlier releases landed within four days of it, v0.3.1 on 2026-09-03 and v0.3.2 on 2026-09-05. That cadence, combined with a release title whose headline item is host-version compatibility, tells you the plugin tracks a moving host. The troubleshooting section confirms this from the other direction: it splits failures into Case A, where the harness works and only the worktable needs updating, and Case B, where the harness itself is down and the advice is to upgrade Harness first with npx @deepseek-ai/dsh web. A release candidate in the compatibility title is a signal that the target is not a frozen interface. If you pin a DSH version and do not move it, you inherit whatever worktable release matched that pin. If you follow DSH forward, you should expect to re-run the install command, restart dsh web and refresh after host upgrades. The update check in the worktable Settings panel, with an amber badge and a Copy AI prompt option, is the documented path for the first case.

Where a plain browser tab or a terminal multiplexer fits better

The obvious alternative for the workspace half is a terminal multiplexer such as tmux or a plain set of browser tabs, and the difference is not cosmetic. A multiplexer owns the process, so panes survive a GUI restart and the layout is a text file you can version. dsh-worktable owns neither: its panes are rendered into the host shell overlay, its state is in localStorage, and its terminal pane is a WebSocket route that speaks PowerShell on Windows. What it adds in exchange is the binding between a project and a harness conversation, which a multiplexer has no concept of, and the control room, which reads host session snapshots that no external tool can see. So the split is clean. If your work is mostly shell sessions in fixed directories, a multiplexer is the smaller and more durable tool. If your work is mostly agent conversations that need a project-shaped home and an overview of what is running, the multiplexer cannot do that job at all. There is no partial overlap to weigh. The plugin's value is entirely a function of how much time you spend inside DSH.

Licence and maintenance expectations

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. That is the standard permissive position and it removes licence negotiation from the adoption decision. This is not legal advice, and if you redistribute the plugin inside a product you should read the licence text yourself. On maintenance, the material supports a narrower statement than a health claim: the project is not archived, the last push is 2026-09-06, and there are regression suites named in the README, including a 20-step functional diagnostic at 04_test/functional-diag.cjs described as a strict gate, a path matrix, update-check scenarios, an 8-scenario anchor DOM regression that runs in the release pipeline, and a data-home resolution regression covering three groups. Those tests being in the release pipeline is a concrete fact about process, not a guarantee about any future DSH release. The realistic maintenance cost for an adopter is the upgrade loop described in the troubleshooting section: check the badge, or re-run the add command, restart, refresh.

Editorial conclusion

Adopt dsh-worktable if you already run DeepSeek Harness 0.1.2-rc.1 or a compatible build and want project windows and a session overview without leaving the host GUI. Do not adopt it if you are not on DSH, if you need a stable API surface across harness versions, or if you cannot tolerate plugin breakage after host upgrades. Before installing, verify the DSH version your profile targets, confirm the install path (release tarball or a local clone without spaces in the absolute path), and check that your layouts and bindings survive a restart by inspecting the dsh.worktable.* keys in localStorage.

Official sources

1. Aisland-SJL/dsh-worktable on GitHub
2. Issues
3. License: MIT
4. README
5. Releases