@local/dsh-mcp-server

LIMITATIONS

Known limitations

- **The advertised URL is the listener's own.** The row's `url` and `DSH_WEB_URL` still win, but with neither set the endpoint file follows `ctx.webServer` (`protocol`/`host`/`port`) once the app is ready, so a Harness whose GUI port is OS-assigned no longer publishes a dead `19387` URL to stdio bridges and other clients. - **Code changes need a Harness restart.** Re-enabling a bundle reloads its row but reuses the already-imported module generation, so edited plugin code only takes effect after restarting DSH. Config changes reach the running instance immediately; changing a bundle's package path may report `restart-required`. - **The bearer token is a local secret.** The desktop profile keeps it in `$DSH_HOME/profiles/desktop/cordis.patch.yml`, and `selfcheck/cordis.patch.yml` repeats it. Rotate by updating both places. It authorizes full DSH session control over loopback, so treat it accordingly. - **Localhost only.** The endpoint rides the Harness web server, which binds loopback. Exposing it to another machine is a deliberate networking change, not a plugin setting. - **Approval and user questions.** A turn started over MCP runs with the session's own approval and sandbox policy (`permissionPreset`, or the deployment default); if a delegated turn needs approval, the prompt appears in the Harness GUI like any other session. Switching a session's preset from the GUI (`/permission`) and over MCP write the same durable events, so the last writer wins per session. - **Commands are immediate and per agent.** `dsh_run_command` runs on the addressed agent's command layer (global + that agent's preset), so a preset-scoped command such as `/compact` may be absent for another session. It is not queued behind a running turn and it can mutate session state (`/permission`), so it carries the same authority as typing the command in the GUI; `dsh_list_commands` first is the way to know what a session accepts. - **Task-start sync is its own row.** `dsh-work-sync` is inserted by this bundle's patch and owns its config; without it the endpoint still serves MCP, `dsh_status.sync.present` is `false`, and saving the switch explains which row to add. Its engine state is in memory, so reloading that row drops questions that were still open. A profile that carried the old `syncOnStart` on the `dsh-mcp-server` row keeps it only as a hint — the sync row's own config is authoritative. - **The settings page keeps the default route and row key.** `configPath`/`entryId` change where the Host serves the route and which row is written, but the browser half is built with `/mcp-config` and `<package>#<row id>`; a renamed route or row needs a matching build. - **The local surface needs the Harness tool registry.** `ctx.tools` (`@deepseek-ai/dsh-tools`) is composed in every shipped profile; without it the tools simply stay MCP-only and the log says so. - **Adding the browser half needs a restart.** The Host half's tools land when the row reloads, but the Web client graph is composed at boot, so a new `lib/client.js` or `dsh.client` declaration shows its **Configure** page only after restarting DSH. - **Opened tools stay open for the session.** `dsh_mcp_open` registers into the calling agent's scope and nothing removes them before the agent is disposed, so a session that opens everything keeps paying for it. Open the few tools a task needs; use `dsh_mcp_call` for one-offs. - **Grouping is the sidebar's own membership record.** A Session's project is recorded, not derived while rendering, so "it runs in that directory" is not enough — something has to attach it. This plugin does that for the Sessions it starts and, once, for the ones it started before, and it only ever joins a project that already exists. - Sessions started over MCP are ordinary DSH sessions: they appear in the Harness session list and can be opened and continued in the GUI.