Windows：官方 SDK runtime 在默认配置下 pwsh 工具全灭——且沙箱故障被误报为命令自身的失败

[YaphetHayate]

Windows：官方 SDK runtime 在默认配置下 pwsh 工具全灭——且沙箱故障被误报为命令自身的失败

概要

在 Windows 上，官方 pip 安装的 SDK + 默认配置，pwsh 工具 100% 调用失败——包括 Write-Output hi 这种最简单的命令——每次失败都是同一副样子：

[stderr]
error: --profile <name> is required
[exit code: 1]

命令根本没有执行。根因：单文件（SEA）runtime 下，沙箱 runner 以 [process.execPath, runner.js, ...] 方式启动（packages/sandbox/sandbox-local/src/index.ts:557-563），而此时 process.execPath 是 runtime exe、其入口是 dsh CLI——runner 路径被当成 CLI 参数解析，在 apps/cli/src/args.ts:140 被拒绝。"process.execPath 能像 node 一样执行 JS 文件"这个假设在 npm/开发部署下成立，在 SEA exe 下不成立。

当前不存在任何能让 confinement 在 SEA runtime 下工作的配置。唯一出路是 DSH_PERMISSION_MODE=danger-full-access，而它会整体关闭 confinement——Windows 嵌入式用户被迫在 "shell 工具不可用" 和 "安全机制全关" 之间二选一。

环境

• Windows 11 x64（存在 Windows PowerShell 5.1，resolvePwshPath() 解析成功）
• deepseek-harness-sdk / deepseek-harness-runtime-bin 0.1.2rc1（PyPI）
• 已核对当前 origin/master（0.1.3-alpha.1）：windowsAclRunnerInvocation() 逐字相同

复现

无需模型——直接 spawn 沙箱服务拼出的 argv：

$exe = "<venv>\Lib\site-packages\deepseek_harness_runtime\runtime\deepseek-harness-sdk-runtime-win-x64.exe"
& $exe .\runner.js --workspace D:\tmp
# stderr: error: --profile <name> is required   exit 1

Agent 层：任意 DeepSeekHarness（默认 profile、无 patch）让它跑一条 pwsh 命令，工具结果就是同样的错误。默认组合必然踩中：dsh-base 在 win32 挂载 pwsh-sandbox，sandbox-policy 默认 workspace-write。

误报

sandbox-local 的 README 承诺："When no runner is usable the provider fails closed with SANDBOX_UNAVAILABLE — a command never silently runs unconfined." runner 故障按契约签名（exit 127 + stderr 含 windows-acl-run:）分类。SEA 下的失败表现为 exit 1 + commander 报错文本，签名永不匹配——沙箱自身的故障被报告给模型，伪装成命令自身的失败。从 agent 视角看连 Write-Output 都"失败"，且错误指向 dsh CLI 配置而非沙箱——外部排查极其困难。

唯一的绕过会关闭全部 confinement

DSH_PERMISSION_MODE=danger-full-access 是唯一逃生口，而代价是一次性失去全部：

• 无 confinement：SandboxPwshExecutor.run() 在 confine() 之前短路；每条命令——及 agent spawn 的每个进程——以宿主用户完整权限运行（工作区外任意写入、不受限网络）。
• 无审批闸门：dsh-base 把 approval 策略绑在同一个变量上（full-access 下为 'never'）。
• 级联放大：每个 subagent 继承部署模式，在 agent 扇出的每个 worker 上成倍复制。

于是 Windows 嵌入式用户只能在 "永远坏掉的 shell 工具" 和 "无任何安全机制地跑 agent" 之间选。评测 harness 场景更尖锐：本应由沙箱机械强制的边界（把 agent 挡在它不该读的文件之外）退化为仅存于提示词的约束。

这是受支持的使用路径吗？

是的——sdk-minimal 硬编码了 sandbox-policy.mode: danger-full-access（packages/bundle/sdk-minimal/cordis.patch.yml），说明嵌入式场景跑 full-access 是团队已知且有意设计的模式。但 full sdk profile 是 SDK 文档化的默认（README 第一个示例就是它，配了一条必须用 shell 的提示词），且需要完整工具面（skills、subagents）的负载用不了 sdk-minimal。因此 full sdk + SEA runtime + Windows 是受支持、有文档——但默认即坏——的组合。SDK 的全部测试都以 full-access 启动（python/sdk/tests/test_bundled_runtime.py:40,79、manual_sdk_agent_smoke.py:72），这大概就是默认路径的损坏未被察觉的原因。

---

可应要求提供完整 traces（DSH 会话日志、最小复现脚本）。

[kittimzhe]

我在自己的 fork 里把这条链核了一遍，你的定位是对的，几个关键点补充确认一下：

windowsAclRunnerInvocation() 返回 [process.execPath, builtEntry]，注释里自己写着「a future native-exe runner keeps the same argv contract and only swaps these entries」——也就是说这个假设是被记录在案的，只是从来没在 SEA 下兑现过。SEA 下 execPath 是 runtime exe 自己，入口是 dsh CLI，所以 runner.js 落到 commander 手里就成了第一个位置参数，被 apps/cli/src/args.ts 的 --profile 检查拒绝，exit 1。

两个让这个问题格外隐蔽的点：

一是 win32 链只有一个候选。chainVerdict() 里 sole candidate 不走 probe（「A sole candidate needs no arbitration」），所以坏掉的 runner 每次都被无条件选中，探测机制完全没机会拦住它。

二是失败签名对不上。windows-acl 的 runner 故障契约是 exit 127 加 windows-acl-run: 前缀，SEA 下实际是 exit 1 加 commander 的报错文本，RUNNER_FAILURE_RULES 永远匹配不到——这就是误报的直接来源：沙箱没起来，模型看到的却是命令自己失败了。

修复上我倾向于两个方向：

1）治误报，可以单独先合：把 dsh CLI 的参数拒绝签名（error: --profile）加进 windows-acl 的故障规则。有个细节要注意：这条规则目前是 exit-gated 的（allowedExitCodes: [127]），而 SEA 下的失败是 exit 1，光加签名到不了检查那步——所以要么把 exit 1 连同签名一起放行，要么给签名单独开一条不 gate exit code 的规则。这样哪怕 SEA 判定还没做，这类失败也会被归类成 runner 故障而不是命令失败，至少 fail-closed 的承诺保住了。

2）治本：Node 22.9+ 有官方的 node:sea 模块，isSea() 一个调用就能判定当前是不是 SEA runtime。在 windowsAclRunnerInvocation() 或链选择处判定 SEA 后，win32 链应当直接判定 windows-acl unusable、抛 SANDBOX_UNAVAILABLE——在 SEA runner 有专门入口之前，宁可明确报不可用，也不要让每条命令带着一个起不来的沙箱假跑。测试可以用现有的 internals 注入 hooks 模拟 SEA 场景（local.spec.ts 里 bwrap/landlock 的链测试都是这么做的），Unix 侧逻辑不回归。

我在 macOS 上，Windows SEA 没法真机跑，所以 fork 分支能覆盖的是源码级修复和测试设计，真机验证还是得靠 Windows 环境。