Headless mode: support --resume <session-id> / session attach to avoid per-task cold starts

[ybkin1]

Summary

Headless runs are strictly one-shot: every invocation is a cold process, and if a run is interrupted (timeout, crash, cancellation), its session is effectively discarded — the orchestrator must re-run the whole task from scratch in a fresh process. In our orchestration workload the fixed cost per cold start is significant: loading the configured MCP servers alone measured 30-75 seconds per run. A --resume <session-id> flag (or attach semantics against a persistent session) would let orchestrators retry or interrupt long tasks without paying the cold start and re-priming cost every time.

Background & Evidence

• We drive dsh headless from an external process-level orchestrator (task queue with retries, timeouts, cancellation). Every dispatch pays full runtime boot; in our configuration (a mix of resident local HTTP MCP servers and spawned stdio servers), measured MCP bring-up accounts for 30-75 seconds per cold start.
• Any interruption — orchestrator-side timeout, crash, or cancel — loses the in-flight session: partial progress cannot be continued, so the retry repeats the entire task (tokens plus wall clock plus another cold start).
• Our current workaround is organizational: we keep per-task scope deliberately small to bound the loss of an interruption. That caps achievable task size rather than solving the cost, and long tasks remain uneconomical to retry.

Failure Mode or Reproduction

1. Run a headless task with MCP servers configured; note the startup latency (30-75 seconds in our setup).
2. Interrupt the run mid-task (timeout, cancel, or process kill).
3. Re-run the task: a new cold process boots, MCP servers re-initialize, and the task starts over — there is no way to continue from the previous session's context.

Proposed Fix

Any of the following would help, in increasing power:

• dsh --resume <session-id> (headless): load the existing session's history and continue it with the new prompt, appending to the same session log.
• Early session-id exposure: print the created session id as the first stdout line (or accept --session-id <id> to choose it), so orchestrators can resume deterministically after a failure.
• Attach semantics: a longer-lived session server that headless invocations attach to, amortizing MCP warm-up across many sequential tasks.

Even the minimal resume flag would convert "interrupted = total loss" into "interrupted = retry from last state".

Additional Context

• dsh: @deepseek-ai/dsh 0.1.1-rc.2 (developer preview)
• OS: Windows 10 x64 (build 10.0.18363)
• Node.js: v22.23.2

[liyangbing]

这个需求可以先区分“进程 attach”和“Session resume”：前者复用已启动的 host/MCP 进程，后者只要求持久化的 session/event log 能在新进程中继续。即使暂时没有 --resume CLI，也可以先定义稳定的 session-id 输出和恢复契约：

• 被中断的 turn 要保留已提交 event seq，并将未完成的 tool call 标成可恢复/需重新确认，而不是把半条消息当完成；
• 新进程 attach 时校验 agent definition/version、workspace、sandbox provider 和 credential reference；
• SSE/事件读取支持 Last-Event-ID，客户端先补齐事件再发送新的 message；
• retry 需要明确是“继续同一个 session”还是“创建新 session”，并在审计里区分。

SandBase Harness 已把这个模型做成 HTTP/SDK/MCP 可调用的 runtime：同一个 session_id 可以继续发送消息，事件流支持从指定 Last-Event-ID 恢复，失败 Session 允许追加新消息恢复并保留完整 event log。Session API、事件流示例 和 MCP run_session 可以作为实现参考。

这不等于已经提供 DSH 的 --resume 命令；CLI/Host 仍需决定 MCP 连接复用、sandbox 生命周期和中断 turn 的语义。

[ybkin1]

Follow-up to my own report above, after a deeper read of the sources. Two corrections — one about what an interruption actually loses, one that makes the ask considerably smaller than I implied — plus a note on how the 30-75 s figure was measured.

1. An interrupted headless session is not discarded. I wrote that the session is "effectively discarded" and that an interruption "loses the in-flight session". That overstated it: the headless runner flushes the session to disk before exiting, so the interrupted session's file survives on disk. What is missing is any way to continue it headlessly: the headless command line parses only the task positional and --help, and the runner mints a fresh session-<uuid> id per run without ever exposing it before exit — so even a manual continuation has nothing deterministic to point at. (This also brings the report in line with the session-log durability premise of my earlier torn-read discussion.)

2. The resume machinery already exists — headless just does not wire it. Reading the shipped packages: the agent registry defines a create/resume factory contract (resume: "Load a persisted session and resume an agent on it"), and interactive profiles already accept a resume flag (dsh --profile tui --resume <session>). The gap is confined to the headless driver. That changes the effort assessment from "build resume support" to "surface an existing resume path" — the minimal --resume <session-id> flag is mostly wiring, which is why it remains my top pick from the fix ladder, ahead of session-id exposure and attach semantics.

3. How the 30-75 s MCP bring-up number was measured. Since I did not say: it is a wall-clock measurement taken in our configuration (a mix of resident local HTTP MCP servers and spawned stdio servers), by timing individual cold headless starts — a handful of runs, one Windows deployment, no instrumentation. It is an environment measurement offered as motivation, not a benchmark; I would not generalize it beyond "cold starts with several MCP servers cost tens of seconds in this setup".

Environment: @deepseek-ai/dsh 0.1.1-rc.2 (developer preview), Windows 10 x64.

Thanks to the maintainers and everyone engaging in this community — this follow-up is the product of a deeper source read before pushing the thread further. I hope the feasibility point is the most useful part: the expensive-sounding feature is mostly wiring.