[bug] Windows workspace-write 沙箱下执行 npm 包装的 CLI 永久阻塞，并把整个 dsh web 进程拖死

[Elysees]

环境

• OS：Windows 10 专业版 10.0.19045（x64）
• Shell：Windows PowerShell 5.1.19041.3803
• Node：v24.16.0
• dsh：0.1.7-rc.1，dev 启动 node --import tsx/esm apps/cli/src/bin.ts web（HEAD 46a7f68b09）
• 触发会话权限：workspace-write（sandbox workspace-write + approval ask）
• 对照会话权限：danger-full-access（sandbox 不限制 + approval never）
• 与模型无关：gpt-6-sol、deepseek-flash 均复现
• 与 shell 工具实现无关：复现会话用的是 fresh-process 的 pwsh 工具（非 tool-pwsh-persistent），已核对会话日志中记录的 tool schema
• 被调用命令：lark-cli 1.0.64（@larksuite/cli）。PowerShell 解析到 npm shim lark-cli.ps1 → node scripts/run.js → execFileSync(bin/lark-cli.exe, args, { stdio: 'inherit' })，原生 exe 约 40 MB

现象

在 workspace-write 会话里，模型用 pwsh 工具执行 lark-cli，调用永久不返回：

• 会话日志停在 tool/call，之后没有 tool/result（两个会话、两次独立复现）
• dsh web 进程随后单核持续 70%~100% CPU，累计 CPU 到手动 kill 时分别为 144.8s、277.6s
• 采样 6 秒：读写 I/O 增量为 0，其他 I/O 约 19.9 万次；无对外连接；无任何子进程
• 已有 loopback 连接保持 ESTABLISHED，但新请求全部超时（curl --max-time 6 http://127.0.0.1:3080/ → 0 字节）
• 传入的 timeoutMs: 120000（另一次未传）没有产生任何结果，只能手动 kill 恢复

复现步骤

1. pnpm dsh web。默认权限预设即 workspace-write，见 packages/bundle/base/cordis.patch.yml:247：
   mode: !!js process.env.DSH_PERMISSION_MODE ?? 'workspace-write'
2. 在 web 会话里让 agent 执行 lark-cli --version
3. 调用永不返回，整个 web 服务随之卡死（HTTP 无响应）

最小复现建议：凡"Node/npm 包装的 CLI"都应能触发，可对照 pnpm --version、npx --version（未逐一验证）。

对照实验：同一台机器、同一条命令、同一个工具

会话权限	sandbox / approval	lark-cli --version	lark-cli docs +fetch
workspace-write	workspace-write / ask	永久阻塞	永久阻塞
danger-full-access	不限制 / never	0.1~0.5s 返回 lark-cli version 1.0.64	0.4~0.5s 返回 JSON

DSH 环境之外、无沙箱、stdout 为管道时的补充对照：

• lark-cli --version、lark-cli docs +fetch ... 均 0.4~0.5s 返回
• 套上 tool-pwsh 同款 marker wrapper 后同样正常
• LARKSUITE_CLI_NO_UPDATE_NOTIFIER=1 / LARKSUITE_CLI_NO_SKILLS_NOTIFIER=1 开关无差异

唯一变化量是沙箱模式。

推断的根因

观测到的事实：只有受限模式会挂。受限模式下命令经 ctx.sandbox.confine() 包装，用受限令牌 argv 走继承的子进程路径（packages/shell/pwsh-sandbox、packages/sandbox/sandbox-windows-acl）。

推断：tool-pwsh 的模型侧说明本身写明受限模式下"程序无法打开命名管道，Node 的 child_process.spawn/exec（默认 stdio: 'pipe'）会 EPERM"。lark-cli 正是这种形态（Node shim → 原生 exe → 内部再起子进程）。预期是干净的 EPERM/拒绝，实际是在受限令牌下阻塞：子进程不退出、不报错、几乎不产生 I/O；父进程事件循环被占住，定时器也不再触发，最终整个 web 服务失去响应。

具体阻塞点尚未定位：本机没有 PTY 复现手段，卡死进程启动时也未带 --inspect，拿不到栈。

影响

• 任何 Node/npm 安装的 CLI（很常见）在 workspace-write 下都可能卡死会话
• 更严重：一次工具调用能拖死整个 dsh web，超时兜底不生效，只能手动 kill

已排除

• 模型问题：两个不同模型同样复现
• lark-cli 自身缺陷：无沙箱环境下秒回
• tool-pwsh-persistent（持久 PTY shell）：复现会话用的是 fresh-process pwsh，schema 与日志已核对
• notifier 干扰：A/B 无差异

建议修复

1. 沙箱层：受限令牌下无法完成的管道/句柄操作要变成结构化拒绝（EPERM / SANDBOX_DENIED），不能阻塞等待。
2. 子进程/工具层：超时必须真正生效；子进程异常退出或失联必须上报；单个工具调用不得让宿主进程失去响应。
3. 诊断能力：受限运行补子进程生命周期日志，并支持用 --inspect / --prof 抓热点，便于定位此类卡死。

下一步排查（可选）

用 node --prof --logfile=<dir> --import tsx/esm apps/cli/src/bin.ts web 起服务，复现后强杀进程，再用 node --prof-process 读热点函数，可直接看到卡在哪个循环。

---

相关：#7720（Windows ACL 沙箱初始化失败，属同一区域但不同故障）