dsh-task-dispatch: dispatch a task to a real DSH session by workspace, with a persistent task ledger

[vinson1101]

What it does

dsh-task-dispatch lets anything that can speak HTTP hand a task to a real DSH session, and read the result back later. It exists because moving work between two agent clients by copy-paste is the slowest part of the loop.

• Target by workspace path or session id. Given a project directory it reuses the best existing main session there (a running one first, then the most recently active), or creates one if none exists. Subagent, archived and migration-pending sessions are refused with a reason instead of being guessed at.
• Every delivery is a persisted task record — taskId, requestId, session, workspace, status, result — stored as JSON under $DSH_HOME/relay/tasks/, so it survives a restart.
• GET /tasks/:id is read-only: no message is sent, the model is not invoked.
• POST /wait waits for a terminal state. A timeout neither cancels the task nor resends it.
• Results are attributed to a turn, not to "idle". The plugin finds its own delivered message by requestId in the session log, takes the turn that contains it, and treats turn/end as the terminal evidence. When attribution fails, the task is surfaced as awaiting-user rather than reported as completed.

Why it has zero dependencies

dependencies and peerDependencies are both empty; it imports only Node builtins and calls services the host already runs. This is deliberate: a bridge that pinned old @deepseek-ai/* versions once installed a second copy of those packages, and the host then loaded the wrong one. Zero dependencies makes that failure mode structurally impossible.

Install

dsh plugin --profile desktop add https://github.com/vinson1101/dsh-task-dispatch/releases/download/v0.6.0/dsh-task-dispatch-0.6.0.tgz

An optional MCP adapter in mcp/ exposes it to Codex and other MCP clients as 7 tools.

Limitation, stated plainly

There is no completion callback. The plugin never pushes a result to the caller; retrieval is pull-only (dsh_result / dsh_wait). The notify field is a ledger for an optional webhook, not proof that a caller received anything.

Repo: https://github.com/vinson1101/dsh-task-dispatch

中文

按工作空间或会话 id 给真实的 DSH 会话派发任务，结果写入持久任务台账，查询只读、不触发模型；超时不取消也不重发；零依赖。没有完成回传，取结果只能主动查。

[vinson1101]

Update: 0.6.1 is out, and it closes a security gap an external reviewer found in 0.6.0.

0.6.0 allowed unauthenticated access when no token was configured, and validated neither Origin nor Host. Any local process could read the task ledger or dispatch work into sessions; under some browser conditions a web page could attempt the same.

0.6.1 changes:

• Auth on by default — a 32-byte bearer token is generated on first start and kept in ~/.dsh/relay/token (mode 600). Opting out requires an explicit allowAnonymous: true.
• Host validation — non-loopback Host → 403 (blocks DNS rebinding).
• Origin validation — a present, non-local Origin → 403.
• Content-Type validation — POST without application/json → 415 (blocks simple-form CSRF).

Release: https://github.com/vinson1101/dsh-task-dispatch/releases/tag/v0.6.1

If you are running 0.6.0, please upgrade — the old tarball is unchanged and still open.