[Bug/建议] Windows 沙箱内无法启动 Chromium 系浏览器（0x80000003）—— 根因定位与修复建议

[z1258]

调查报告：Windows 沙箱内无法启动 Chromium 系浏览器

提交对象：DeepSeek Harness 项目
报告日期：2026-09-13
环境：Windows 11 · dsh 0.1.5-rc.2 · 沙箱模式 workspace-write
相关已有讨论：#997（TLS 失败，同源）· #2850 · #5322（dsh-browser 崩溃）· #986

---

TL;DR

Windows 沙箱内可以启动普通 GUI 程序（notepad 实测成功），但启动不了任何 Chromium 系浏览器 —— 崩溃码 0x80000003。

根因是已经文档化的沙箱约束：受限令牌的 restricting SID 列表是 [logonSid, Everyone]，而命名管道的 client 端打开没有任何 restricting SID 被授予；Chromium 的 Mojo IPC 全走命名管道 ⇒ 打开失败 ⇒ __debugbreak()。这与 #997 报告的 TLS 失败（SEC_E_NO_CREDENTIALS）是同一个 pass-2 语义的两个表现。

建议：方案 A（宿主侧代抓取 + 文档化）—— 改动小、直接解决 agent 拿不到网页正文的痛点。

---

摘要

沙箱内可以启动 GUI 程序，但无法启动任何 Chromium 系浏览器（Chrome / Edge / Electron 应用）。

这是 @deepseek-ai/dsh-sandbox-windows-acl 已经文档化的已知限制的必然结果，不是新的 bug。但对 agent 的实际能力边界影响很大 —— 它意味着沙箱内的 agent 无法用浏览器做任何事，而现代站点几乎全是 HTTPS + JS 渲染，web_search 的标题+链接远不够。

核心机制一句话：受限令牌的 restricting SID 列表是 [logonSid, Everyone]，而命名管道的 client 端打开所请求的写访问没有任何 restricting SID 被授予 → Chromium 的 Mojo IPC 全部走命名管道 → 打开失败 → __debugbreak() → 0x80000003。

---

一、实测现象

在本机沙箱内（workspace-write）逐项实测：

目标	结果
cmd.exe /c echo（继承 stdio）	✅ 成功
Start-Process cmd -RedirectStandardOutput	✅ 成功
notepad.exe（普通 GUI 程序）	✅ 成功启动
msedge.exe --headless=new --disable-gpu about:blank	⚠️ 主进程启动、/json/version 在 1 秒内响应（Edg/153.0.4234.32）、/json/list 返回 7 个标签页 —— 但随后崩溃
chrome.exe --headless=new ...	❌ 退出码 0xFFFF7001
崩溃表现	Windows 错误对话框：应用程序发生异常 unknown software exception (0x80000003)

⇒ 准确表述不是「不能打开软件」，而是「能打开，但用命名管道做进程间通信的程序会崩」—— 而 Chromium 系全靠这个。

---

二、根因（官方文档 + 源码级定位）

2.1 官方文档已写明（dsh-sandbox-windows-acl/README.zh.md「已知限制」）

受限孙进程的管道 stdio 捕获不可用。 libuv 的管道 stdio 用的是 NAMED pipe，其 client 端打开所请求的写访问没有任何 restricting SID 被授予（是 Win32 层的默认 SD 模板，而非令牌默认 DACL），因此受限进程内 spawn(..., { stdio: 'pipe' }) 以 EPERM 失败；继承与忽略 stdio 的 spawn 可用，匿名管道（PowerShell 的管道）因受限令牌默认 DACL 携带 restricting SID 全权 ACE 而可用。

同一份文档还写明（与本次实测一致）：

控制台隔离不可用。 以 CREATE_NO_WINDOW / CREATE_NEW_CONSOLE 创建的子进程在 DLL 初始化期间以 STATUS_DLL_INIT_FAILED（0xC0000142）死亡。

Authenticated Users 在两种列表中都不存在 —— WMI 命名空间安全检查失败（0x80041003）。（本次实测：WMI Win32_Process.Create 拒绝访问 ✓ 一致）

模式与令牌列表：workspace-write = 登录 SID + Everyone + 工作区 SID + 临时 SID；read-only = 登录 SID + Everyone。

2.2 讨论 #997 给出了源码级定位

受限令牌 pass-2 检查作用于所有安全对象访问（不止写）。Schannel 的 AcquireCredentialsHandle 涉及 LSA/安全包内部对象访问，被 pass-2 拒绝 → SEC_E_NO_CREDENTIALS。

实证对照：

• 真实沙箱 → SEC_E_NO_CREDENTIALS
• 变体 A（仅 DISABLE_MAX_PRIVILEGE、无限制 SID）→ curl 成功 —— 证明限制 SID 列表是必要条件
• 变体 B（仅限制 [Everyone]、缺 logonSid）→ 0xC0000142 —— 与官方文档注释一致

⇒ Chromium 的 Mojo 命名管道打开失败，与 Schannel 失败是【同一个 pass-2 语义】的两个表现。

---

三、同类案例：三个项目撞过同一堵墙

3.1 openai/codex PR #20270 —— 修法在沙箱侧

Windows named pipes created by tools like Ninja use the platform's default named-pipe ACL when no explicit security descriptor is provided. In the elevated sandbox, the pipe owner has access, but the write-restricted token can still fail its restricted-SID access check because the sandbox user SID was not in the restricting SID set. That causes child processes to exit successfully while Ninja never receives the expected pipe completion/close behavior and hangs.

Fix: Including the elevated sandbox user's SID in the restricting SID list lets the restricted check succeed for these owner-scoped pipe objects without broadening the unelevated sandbox to the real signed-in user.

⇒ 关键：Codex 的修法是【把所需 SID 加进 restricting 列表】，改动在沙箱侧，被隔离的程序侧无法自救。

3.2 NousResearch/hermes-agent PR #66842 —— 修复阶梯

On some Windows hosts the GPU/renderer sandboxes die with STATUS_BREAKPOINT（0x80000003 / exit -2147483645）. Chromium then FATAL-exits before the UI is usable.

修复阶梯：

1. ACL 修复（首选）：icacls 给安装目录授 S-1-15-2-2（ALL APPLICATION PACKAGES）RX
2. --no-sandbox（次选）：仅在签名确认是 GPU/renderer 断点死亡时启用
3. 按版本 sticky，升级后重新探测一次

3.3 electron/electron#51761 —— canonical issue

Electron apps crash with exit_code=-2147483645 because the folder's DACL contains orphaned zombie SIDs（S-1-15...）. Granting permissions to S-1-15-2-2 or running icacls /reset fixes the crash.
已知临时解法：启动时加 --disable-gpu-sandbox。

⚠️ 但注意：hermes 与 electron 的根因是「DACL 里缺 ACE / 有僵尸 SID」，属于环境损坏；DSH 沙箱的根因是受限令牌的 pass-2 语义，属于设计约束。两者症状相同（都是 0x80000003），但修法不能照搬 —— icacls 在 DSH 沙箱内被明确拒绝（本次实测：Access is denied）。

---

四、建议

方案 A（推荐，改动小）：文档化 + 宿主侧代抓取

1. 在沙箱文档明确写：受限令牌下沙箱内无法启动 Chromium 系浏览器，也无法建立 TLS/HTTPS 连接（后者见 [Bug Report] Windows 沙箱 shell 无法建立任何 TLS/HTTPS 连接（SEC_E_NO_CREDENTIALS）——受限令牌限制 SID 列表使 Schannel 凭据获取被拒 #997）
2. 提供宿主侧的网页抓取能力（类似 web_search，由宿主进程发起、返回正文）—— 让 agent 在受限模式下仍能拿到网页内容
3. 可选：提供宿主侧的浏览器控制插件（见下方「参考实现」）

理由：直接解决 agent 的实际痛点，不动沙箱边界。

方案 B（根治，改动大）：沙箱 shell 改用非受限令牌 + 文件系统 ACL 强制

进程不再用受限令牌做全局限制，写限制改由文件系统 ACL 强制（复用现有的 capability-SID 授权机制）；read-only 模式需重设计（只读 ACL / job object）。

代价：需全面回归沙箱边界。收益：TLS 与 Chromium 一并解决。

方案 C（研究路径）：补充 restricting SID 列表

参照 Codex 的做法，识别 pass-2 拒绝的具体安全对象并补充所需 SID。实验成本高、收益不确定。

不建议：在沙箱内加 --no-sandbox

本次实测 --no-sandbox 无效（Chromium 即使关掉自己的沙箱，浏览器↔渲染进程仍走 Mojo 命名管道）。而且它会削弱 Chromium 自身的安全边界。

---

五、我试过并失败的（避免别人重复）

在 Windows / workspace-write 下，以下全部失败：

--no-sandbox · --headless=new · --disable-gpu-sandbox · --single-process
--in-process-gpu · --no-zygote · --disable-gpu --disable-software-rasterizer
--disable-features=NetworkServiceSandbox,NetworkServiceInProcess
--enable-features=NetworkServiceInProcess · --disable-features=RendererAppContainer
--disable-renderer-appcontainer
以上各种组合

WMI Win32_Process.Create        → 拒绝访问
schtasks /Create /Run           → The system cannot find the path specified
explorer.exe 代劳                → 失效
icacls 给自己的目录加 ACE         → Access is denied
.NET Set-Acl 写 DACL            → Attempted to perform an unauthorized operation

唯一「部分成功」的是 --headless=new：主进程起来了、调试端口开了，然后仍崩。

---

六、参考实现（宿主侧，可绕开沙箱）

因为问题在沙箱侧，正确做法是把浏览器控制放在宿主进程。调研到的两个参考：

项目	形态	备注
@deepseek-ai/dsh-browser（rc，npm 未公开）	DSH 官方包，提供 browser_open / browser_act	见 #5322；已知 bug 已修（JSON.parse 裸调、无 onclose、send 无超时、spawn 无 error 监听）
dsh-browser-control（第三方）	DSH 插件，6 个 browser_* 工具	⚠️ launch.sh 是 macOS 专用（$HOME/Library/...、/Applications/Google Chrome.app、pkill），Windows 跑不起来；且拷贝含 Login Data 的凭据副本到 /tmp 后 --kill 不清理

第三方插件的「登录态复用」思路值得借鉴：新版 Chrome 禁止在默认 user-data-dir 上开 --remote-debugging-port，它的做法是把关键 profile 文件拷到隔离目录，再用隔离目录启动。

---

七、证据附录

材料	链接
DSH 沙箱官方文档（含「已知限制」原文）	sandbox-windows-acl/README.zh.md
TLS 失败根因（同源，含源码行号）	#997 · #2850
dsh-browser 崩溃	#5322
Codex 的 restricting-SID 修法	openai/codex#20270
hermes 的修复阶梯	NousResearch/hermes-agent#66842
Electron 的 canonical issue	electron/electron#51761
Chromium Mojo 命名管道源码	named_platform_channel_win.cc

---

本报告由 dsh-desktop-kit 项目在实机调研后整理，全部结论均有实测或官方原文出处；未能证实的内容已明确标注。