沙箱控制台修复 TJZF-4j97/dsh-sandbox-console-fix

dsh-sandbox-console-fix

仅限 Windows。 这是一个 DeepSeek Harness 插件包，让受限沙箱在桌面应用上重新可用：workspace-write 的 shell 调用能再次启动， read-only 也照常工作——不放松任何限制。这个插件包的两条补丁行都带平台守卫，所以在 Linux/macOS 上组合结果不受影响，整个包处于惰性状态。

目标版本为 DeepSeek Harness 桌面版 0.2.0-rc.2——Electron 44.0.0 / Node 24.18.1，已在 Windows 11 22H2 x64 上验证。
已作为 Discussion 上报上游： <https://github.com/deepseek-ai/deepseek-harness/discussions/9280>。
⚠️ 未经任何人工审查

AI 生成的代码。 由 DeepSeek V4.1-flash 端到端地发现、设计、编写并测试，这是一个运行在 DeepSeek Harness 里的 AI 智能体。有人类指挥了这项工作并批准了各个步骤，但没有任何人读过、审查过、审计过或批准过这份代码及其证据。请把它当作来自未知作者的、未经审查的第三方代码：安装前自己读一遍 index.js、console-shim.mjs 和 cordis.patch.yml，不要在任何你不愿运行未审查脚本的地方运行它。

本项目在上游发布的每条评论都附带同样的警告。

先例与佐证

@argszero/cordis-plugin-sandbox-grant-advisor（0.17.0）已经把这种故障形态命名为 native-init 家族并给出了解释：受限子进程始终到不了第一条指令，它被拆成打包后的 GUI 子系统宿主，和一个控制台子系统的 node.exe，后者的 runner 以 DETACHED_PROCESS 启动。它只是个顾问——负责命名和诊断；这个插件包负责修复。它实测出的补救办法（Harness discussions #8193 / #8208）在这里被沿用，包括在 AllocConsole() 前后恢复 runner 的三个标准句柄。更长的机制说明见 discussion #9238，报告见 #9280。

问题

在打包后的 Windows 桌面应用上，workspace-write 下的任何 shell 调用都会立刻失败：

[exit code: 3221225794] # 0xC0000142 STATUS_DLL_INIT_FAILED

pwsh、cmd 和 powershell 都以同样方式失败，MSI 和 Store 打包的 PowerShell 构建都一样，而 danger-full-access 和 read-only 却能正常工作——所以 shell 工具本身没问题， workspace-write 的受限路径才是问题所在。

这个故障需要两个条件同时成立——无控制台的 runner 宿主（Electron 二进制）和 workspace-write。完整矩阵见 docs/VERIFICATION.md。子进程自己创建控制台为何在一种模式下成功、在另一种模式下失败，尚未定位——见该记录的第 5 节和第 9 节；无论如何，这个修复在两种模式下都有效。

根本原因，在已发布的代码里（dsh-sandbox-local，windowsAclRunnerInvocation()）：

if (existsSync(builtEntry)) return [process.execPath, builtEntry];
在桌面应用里，process.execPath 是 DeepSeek Harness.exe —— 一个 Electron 二进制文件，也就是 GUI 子系统映像，永远没有控制台。在同一台机器、同一个父进程上实测：

| runner 宿主 | GetConsoleWindow() |
| node.exe（控制台子系统） | 非零 → 有控制台 |
| DeepSeek Harness.exe（GUI 子系统） | 0 → 没有控制台 |

随后 ACL runner 拉起受限子进程时，不加 CREATE_NO_WINDOW / CREATE_NEW_CONSOLE —— 这是有意为之，因为按 DSH 自己的文档，这类子进程在受限 token 下会在 DLL 初始化阶段死掉 —— 它依赖子进程继承 runner 的控制台。可继承的东西不存在，控制台子系统的子进程就只能自己创建控制台；在 Low 完整性、写受限的 token 下，这次创建会失败，进程以 STATUS_DLL_INIT_FAILED（0xC0000142）退出。

修复方式

多传一个 argv 项，位置正是 DSH 自己的开发路径给同一个 runner 用的位置（[process.execPath, "--import", <url>, entry]）：

shipped: [execPath, runner.js, …profile, --, target]
this: [execPath, --import <console-shim.mjs>, runner.js, …profile, --, target]

console-shim.mjs 在进程没有控制台时调用 AllocConsole()，别的什么都不做，于是受限子进程继承到一个控制台，正常启动。

不变的部分

| | shipped | 使用本 bundle |
| 受限 token（Low IL + 写受限 SID） | ✔ | 完全相同 |
| workspace / private-temp 的 capability-SID 授权、deny ACE | ✔ | 完全相同 |
| 完整性标签、Job 对象、stdio 管道、拒绝方言 | ✔ | 完全相同 |
| runner 与子进程的环境 | ✔ | 完全相同 —— 没有注入任何东西 |
| dsh-fs-sandbox 文件策略 | ✔ | 未改动 |

在受限子进程内部跑了一次逃逸写入测试来验证：四个 workspace 之外的目标全部被拒绝，磁盘上也不存在，而 workspace 内的写入成功 —— 见 docs/VERIFICATION.md。

安装

按 dsh 期望的方式安装 —— 走 Plugin Manager，包安装和 bundle 选择都由它自己完成：

1. 打开 Plugin Manager 页面，从 https://github.com/TJZF-4j97/dsh-sandbox-console-fix 安装 bundle，或者用本目录某个 checkout 的绝对路径。
2. 重启 Harness。
3. 把会话设为 workspace-write，然后跑任意 shell 命令。

不会下载任何东西，也不会请求构建脚本，因为本包刻意不声明任何依赖：index.js 从运行中的 Harness bundle 加载 LocalSandboxProvider，console-shim.mjs 也在那里解析 koffi。Harness 自己的安装器记录的正是如此 —— Packages: +1，零下载，没有待执行的构建脚本。

cordis.patch.yml 挂载这个 provider 的方式是禁用 shipped 的 sandbox 行，插入自己的一行，两行都用 !!js 做平台守卫 —— 这正是 shipped 的 dsh-base 补丁给自己用的惯用法 bash-sandbox 行。这个形状是 Loader 方言要求的：非插入补丁会替换目标行的字段，而真值 name 只是断言已有插件名，所以不能通过覆盖 id 来替换 provider 行。在 Windows 上，组合里只保留一个 ctx.sandbox provider，随包发布的包仍然从 dsh 安装目录解析；在其他平台上，随包发布的行保持启用，本 bundle 的行保持禁用。

手动安装（不推荐）

把目录复制到 profile 能解析的位置，把名字加进 dsh.profile.bundles，然后重启：

Copy-Item -Recurse -Force .\dsh-sandbox-console-fix "$env:USERPROFILE\.dsh\profiles\desktop\node_modules\dsh-sandbox-console-fix"

{ "dsh": { "profile": { "bundles": ["@deepseek-ai/dsh-base", "@deepseek-ai/dsh-web-app", "dsh-sandbox-console-fix"] } } }

推荐走 Plugin Manager 路线：安装失败时 install_bundle 会快照并恢复 package.json 和 pnpm-lock.yaml，并保持 profile 自己的记账一致。

验证

把会话设为 workspace-write：

$PSVersionTable.PSVersion # expect 7.6.6 — not 0xC0000142 Set-Content 'C:\Users\<you>\nope.txt' 'x' # expect [sandbox: file access denied under workspace-write mode] Set-Content '.\ok.txt' 'x' # expect success Remove-Item '.\ok.txt'

不是本 bundle 导致的： 在受限 shell 里，sandbox 会阻止程序之间的管道 stdio，所以 $x = & some.exe … 和 some.exe | Out-Null 会失败（EPERM；PowerShell 把它显示为 StandardOutputEncoding is only supported when standard output is redirected），而裸的 & some.exe …、PowerShell 自己的 cmdlet 管道和文件重定向都能正常工作。这是 sandbox 有文档说明的隔离行为。
不安装任何东西也能复现底层机制：

node scripts/console-probe.cjs # host-console probe
node scripts/console-probe.cjs --host electron # same parent, Electron host
node scripts/full-chain-repro.js --help # drive the shipped runner under both hosts
powershell -File scripts/escape-test.ps1 -Workspace <dir> # confinement check

这些脚本需要的 extracted-runner 路径见 scripts/README.md。

卸载

从 profile 的 bundles 列表里移除 bundle 名（以及依赖），然后重启。不会留下任何系统级改动——Harness 自己拥有的 workspace ACE 和完整性标签不受本 bundle 影响。

兼容性

| 平台 | Windows 10/11，x64 |
| Harness | DeepSeek Harness desktop 0.2.0-rc.2（Electron 44.0.0 / Node 24.18.1）——子类覆盖了 @deepseek-ai/dsh-sandbox-local@0.2.0-rc.2 的一个方法 |
| Node / Electron | 任意版本（--import 要求 Node ≥ 20.6 / Electron 内置 Node ≥ 20.6） |
| 上游报告 | <https://github.com/deepseek-ai/deepseek-harness/discussions/9280> |
| 其他平台 | 覆盖逻辑永远不会被调用；这个包形同虚设 |

它继承的是 Harness 内部类，所以每次升级 Harness 后都要重新检查——上游修复之后（见问题报告），这个包就没必要了。

发现

DeepSeek Harness 的 CONTRIBUTING.md 要求生态插件把自己的 GitHub 项目关联到 dsh-plugin 话题。本仓库已经带上它——同时还带了 dsh、deepseek-harness、sandbox、windows 和 pwsh——所以从该话题列表里就能找到这个插件。

安全

这个 bundle 不会扩大文件权限。它只是让 runner 能分配一个控制台；写入边界依然来自受限 token、写入受限 SID、Low 完整性标签，以及 Harness 的 ACL 授权与拒绝，这些全部原样继承。shim 不访问文件、不创建进程、不修改环境，并且吞掉所有错误。

许可证

MIT