CLI: guard against oversized prompt arguments (Windows ~32K argv limit); add --prompt-file / stdin input channels

[ybkin1]

Summary

When the prompt is passed as a command-line argument, large contexts — exactly the headless/orchestration use case — run into the OS argv limit. On Windows the per-process command line is capped at ~32,767 characters (CreateProcess), so a prompt of that size makes the spawn fail outright, with no error pointing at argv length as the cause. We hit this in practice with an external process-level orchestrator that drives dsh headless runs, and fixed it on our side by writing the prompt to a file and passing a path instead. We suggest dsh itself provide file/stdin input channels plus a pre-spawn length guard with an actionable message.

Background & Evidence

• Our orchestration wrapper initially passed the full task context as a single CLI argument to a headless run. Once task payloads grew into the ~32K-character range on Windows, spawning the CLI failed due to the command-line length limit; the failure mode gave no hint that argv length was the root cause.
• The file-based workaround (persist the prompt to a temp file, pass the path) removed the failure entirely and also keeps multi-KB context blobs out of shell history and process listings — which is why we think an official file/stdin channel is the right fix at the CLI layer.

Failure Mode or Reproduction

1. Build a prompt string larger than ~32K characters.
2. Invoke the dsh CLI with the prompt as an argument on Windows.
3. The spawn fails or behaves unpredictably once the total command line exceeds the CreateProcess limit (~32,767 characters); the resulting error does not indicate that argv length is the problem.

On POSIX the limit is larger but still finite, so the same class of failure exists there for very large prompts.

Proposed Fix

• --prompt-file <path>: read the prompt from a UTF-8 file.
• stdin support: --prompt - (or a --stdin flag) to read the prompt from standard input, pipe-friendly, no temp files needed.
• A pre-spawn length check with an actionable error, e.g. prompt exceeds the platform argv limit (~32K on Windows); use --prompt-file or pipe via stdin.
• Document the per-platform limits in the CLI help/readme.

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]

这个问题在 SandBase Harness 里通过把“大输入”和进程 argv 解耦来处理：CLI 的 message 参数仍适合短文本，但长任务可以直接写入持久化 Session，而不是把完整上下文塞进子进程命令行。

可用入口：

• HTTP：POST /v1/sessions/:id/messages，消息正文在 request body；
• 结构化输入：POST /v1/sessions/:id/events，提交 user.message 事件；
• TypeScript SDK：client.sessions.message(sessionId, text) 或 sendEvent；
• CLI 还提供 session inspect/logs，用于检查已提交的 Session，而不是重新把内容放进 argv。

参考：

• https://github.com/sandbaseai/sandbase-harness/blob/main/src/sdk/client.ts
• https://github.com/sandbaseai/sandbase-harness/blob/main/src/cli/session-commands.ts
• https://github.com/sandbaseai/sandbase-harness/blob/main/docs/api.md#sessions

这不能替代 DSH 的 --prompt-file / stdin 需求；如果仍保留 prompt 参数，建议在 spawn 前做平台相关长度预检并给出明确错误。对超长上下文，request-body/pipe + stable session id 还可以避免 shell history、进程列表和重试时的 argv 泄漏。