[bug] 工作区被贴过"低权限"的标签后不会撕掉--且之后在「完全权限」会话里，工作区内的程序会继承标签并崩溃

[JFYT-648]

bug描述

一个文件夹被 DSH 设为工作区后，只要曾经用「仅可查看」或「工作区内修改」的模式启动过一次会话，
这个文件夹（以及里面的所有文件）就会被贴上"低权限"封条。
该封条不随会话结束、也不随之后切到「完全权限」而撕掉。
从此，从这个文件夹里启动的 Electron/Chromium 程序——刚打包好的应用、乃至一个字节都没改过的官方 electron.exe——
都会在窗口出现之前直接崩掉：退出码 0x80000003，没有日志、没有提示。

因果链（按能观察到的顺序）

1. 在任意磁盘建一个文件夹，在 DSH 里把它设为工作区。
2. 以「仅可查看」或「工作区内修改」启动一次会话 —— 这是正常用法，用户没做错任何事。
3. 结束该会话；之后在同一个工作区上以「完全权限」启动新会话。
4. 此时把任意 Electron 程序的 exe 放进这个文件夹并运行 ⇒ 闪退 / 崩溃 / 报错；把它放到工作区之外运行 ⇒ 一切正常。
5. 原因：第 2 步留下的"低权限"封条还在，而且继承给了文件夹里的所有文件。

复现步骤

1. 在任意磁盘新建一个文件夹，例如 X:\dsh-ws（X: 换成任意盘符，下同）
2. 在 DSH 中把 X:\dsh-ws 设为工作区
3. 以「仅可查看」或「工作区内修改」启动一次会话，随便读写几个文件
4. 结束该会话，在同一个工作区上新建一个「完全权限」会话
5. 把官方 electron.exe（或你自己的 Electron 应用整目录）复制到 X:\dsh-ws\demo\
6. 运行 X:\dsh-ws\demo\electron.exe --version
   • 结果：退出码 0x80000003（命令行显示 -2147483645），什么都不打印
   • 对照：把同一份文件复制到 X:\demo\ 或者C:\ D:\（任意工作区之外的路径）再跑 ⇒ 打印 v35.7.5，退出码 0(正常运行)

环境（本机）

项	值
操作系统	Windows 10 22H2（build 19045.6466，x64）
磁盘	本地固定盘、NTFS（多个盘符都能复现，与盘符无关）
DSH 版本	0.2.0-rc.2
权限模式	该工作区曾以「仅可查看 / 工作区内修改」启动过一次会话；之后在同一工作区改用「完全权限」
复现程序	官方 electron.exe 35.7.5 x64（零改动）＋打包后的 Electron 应用（同为 35.7.5）
工作区根的标签	Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)
树内文件的标签	Mandatory Label\Low Mandatory Level:(I)(NW)（继承而来）
工作区之外（对照）	无该标签
复现结果	工作区内：退出码 0x80000003、无窗口、无输出、无日志；加 --no-sandbox：退出码 0 并打印 v35.7.5
A/B 结论	执行 icacls <工作区> /setintegritylevel Medium 后，同一个探针立即恢复 v35.7.5、退出码 0
定位手段	① 同一二进制换位置的对照；② 调试器读取失败调用的返回码与 GetLastError；③ 离线反汇编，对应公开源码 sandbox/win/src/window.cc
备注	本机未启用 Windows 错误报告（WER），因此没有崩溃转储；不影响复现

一条命令自查当前状态

icacls X:\dsh-ws

若看到 Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)，就是被封条贴住了
（(OI)(CI) 表示这个标记会继承给子目录和文件）；工作区之外的一个普通文件夹看不到这一行。

A/B 已验证：撕掉封条，同一个程序立刻恢复正常。

icacls X:\dsh-ws /setintegritylevel Medium

（可逆：重新用限制模式启动会话时，DSH 会再贴一次。）

查出来的原因

1. 封条就是 Windows 的"低完整性"标记。用带这个标记的文件启动，进程本身也会被降级运行。
2. Chromium 启动时有个必经步骤：给自己建一个私有的"窗口站"（window station，用来隔离它内部各子进程的桌面环境）。
3. 进程被降级之后，Windows 对这个请求回答 拒绝访问（ERROR_ACCESS_DENIED）。
4. Chromium 的代码认为"这一步不可能失败"：它只为"第一次被拒"准备了重试（换成最小权限再试一次），
   第二次还是被拒就直接 NOTREACHED()，执行一条故意的自杀指令。于是进程以 0x80000003 结束。

⇒ 用户看到的就是：没有窗口、没有日志、没有错误框，程序在有机会加载任何应用代码之前就死了。
任何开发者遇到这个现象，第一反应都会是"是不是我这次改动或打包把应用弄坏了"。然后在这条路上越查越远,怀疑不到DSH本身上

为什么用户自己查不出来

• 崩在应用代码执行之前 ⇒ 应用日志里什么都没有，看起来就是打包 / 代码问题。
• Chromium 这条路径不打日志、不弹错误框，只留下一个裸退出码。
• DSH 自带的 diagnose-windows-sandbox-acl 其实已经把 LOW_LABEL=True 读出来并打印了，
  但最终裁决仍是 NOT_THIS_CLASS（它只检查"文件权限不足 / 外来包权限项"这一类问题）
  ⇒ 用户在工具内没有任何路径追到这个原因。

影响面

• 触发条件：Windows + 该工作区曾被「仅可查看 / 工作区内修改」授权过（封条长期残留）+ 从该文件夹里启动 Chromium/Electron 程序。
• 后果：必崩；且症状指向完全错误的方向（"我的改动把打包弄坏了"）。
• 关键点：切到「完全权限」不会清掉封条；会话结束时的清理也故意保留工作区上的这类"长期编辑"。
  设计上认为这些残留"不会生效" —— 但这个"不会生效"只对文件读写检查成立，对进程完整性不成立。
  问题的本质就在这里：一条残留限制，在一个它没被预期生效的维度上仍然生效。

建议修法(只做建议,应该由官方做决定

DSH 侧（任一即可）

1. 权限模式不再限制写入时，把 Low 封条撕掉，只保留写入授权；重新进入限制模式时再贴一次。
2. 或者在工作区里生成 .exe 时给出明确警告（"该目录下的程序会以降低后的权限运行"）。
3. 或者把"工作区上存在 Low 封条"从属性提升为诊断裁决，并附一句人话解释（工具已读到该值，只差这一步映射）。
4. 长期：把"限制会连带影响其它 Windows 子系统"做成一张已知清单 —— 你们已经处理过两例
   （早期 DLL 初始化 0xC0000142、CNG 导致 pwsh 0xE0434352），这是第三例：窗口站 / 桌面的创建。

Chromium / Electron 侧

5. CreateAltWindowStation（sandbox/win/src/window.cc）失败时不要 NOTREACHED() 自杀。
   低完整性、AppContainer、受限令牌都是合法且常见的运行环境；既然代码已经为"第一次被拒"备了重试，
   就说明作者知道它会发生。应当打一条明确日志并降级继续（或给出人能看懂的失败原因）。

临时绕过（临时方案）

• 撕掉封条：icacls <工作区路径> /setintegritylevel Medium
• 或者：构建和运行都放在贴过低权限的工作区之外（应用装到系统默认的程序目录即可）。

省流

工作区一旦被「仅可查看」或「工作区内修改」的模式授权过，就会被打上 Low 完整性封条；该封条不随会话结束、也不随切到「完全权限」而清除。之后从这个工作区里启动的任何 Electron/Chromium 程序都会在窗口出现前崩溃（ACCESS_DENIED → Chromium NOTREACHED() → 0x80000003）。icacls <工作区路径> /setintegritylevel Medium 后立刻恢复正常（A/B 已验证）。自带诊断脚本已读到该标签，但裁决为 NOT_THIS_CLASS。

给上游（Chromium / Electron）的说明

问题：当"备用窗口站"创建不出来时，Chromium 会直接硬崩（0x80000003，即 NOTREACHED()）。

最小复现：让任意 Electron 35.x 的二进制以低完整性运行（例如镜像文件本身带 Low 强制标签）：
CreateWindowStationW(NULL, 0, GENERIC_READ | WINSTA_CREATEDESKTOP, &sa) 返回 NULL，且 GetLastError() 为 ERROR_ACCESS_DENIED (5)；
代码自带的"换成最小权限重试一次"（访问掩码 0xA）同样失败；随后 CreateAltWindowStation()（sandbox/win/src/window.cc）返回一个非零的 ResultCode，
而调用方把它当作"绝不可能发生" → int3 → 退出码 0x80000003，发生在任何应用代码运行之前（无日志、无弹窗、无输出）。

期望行为：这里的 ACCESS_DENIED 属于合法运行环境（低完整性、AppContainer、受限令牌 —— 代码既然已经为"第一次被拒"准备了重试，说明作者知道这个失败模式会发生）。
应当记录一条明确日志并降级继续（或给出人能看懂的失败原因），而不是 NOTREACHED() 自杀。

关联issue #758/#997/#3207/#1406

该bug由江风与大肥鱼整理

[Howard20181]

独立复现 + 自举场景 + 一个可分离的对照

我在一台 Windows 11（10.0.26300）机器上复现了你描述的因果链，并补四点新证据。

环境：DSH Desktop 0.2.0-rc.2（宿主，FileVersion 实测）+ 仓库 checkout 0.2.1-alpha.2；工作区 C:\dev\repo\deepseek-harness；崩的是仓库 pin 的官方 electron.exe 44.7.0（零改动）。退出码 2147483651 / -2147483645 = 0x80000003。

1) 位置对照（同一份二进制，只换目录；工作区那次是清理前）：从带标签的工作区内启动 → 0x80000003；Copy-Item 到工作区外 → exit=42（探针正常 ready）。这排除了"版本 / 构建 / GPU 驱动"方向。下面 2)–4) 的复现都在工作区外的临时副本上完成。

2) 常见开关都救不了（同一 Low 副本，各跑 3 次）：

flags	退出码
无	0x80000003、0x80000003、0x80000003
--disable-gpu-sandbox	0x80000003、0x80000003、0x80000003
--no-sandbox	0xC0000005、0xC0000005、0xC0000005

--no-sandbox 值得单独提醒：连同另外两次观察，它在同一二进制同一条件下共 5 次里 4 次以 0xC0000005 崩溃、1 次正常启动——不能当作稳定绕过（你那台 35.7.5 上是退出 0，两版行为不同）。

3) 单变量隔离：只要有 Low 标签就够。同一份 dist 复制到工作区外（正常启动），仅执行 icacls <copy> /setintegritylevel (OI)(CI)Low → 立刻变 0x80000003。能力 ACE 与 Everyone 的 DELETE_CHILD 拒绝都不是必要条件。这与你反汇编得到的"备用窗口站创建被拒 → NOTREACHED()"路径吻合。

4) 它为什么"查不出来"：Low 状态下，无论是否加 --enable-logging=stderr --v=1，stderr 都是 0 字节（实测），无窗口、无弹窗、无转储。

两个衍生结论（都已实测）

• 新建文件会重新继承标签：在一个 Low 目录里新建文件，该文件立刻带 Low。所以 pnpm install / 升级 Electron 会在工作区内新解出 dist（electron.exe 的硬链接数为 1，是本地解压而非 store 硬链），新文件重新继承 Low——"只修当前版本 dist 的标签"每次安装都会失效。
• 这是 DSH 自举时的必然冲突：apps/desktop 把 electron 作为 devDependency 装在工作区内，所以 pnpm dev:desktop 必崩；同机打包版（Electron 44.0.0，在工作区外）一直正常，是干净对照。

清理与验证（实测），管理员执行：

icacls '<workspace>' /reset                    # 去掉能力 ACE 与 Everyone 拒绝
icacls '<workspace>' /setintegritylevel Medium # 撕掉封条

之后：electron.exe 探针 exit=42；完整 pnpm start:desktop 起到 dsh web: http://127.0.0.1:… 并完成账号认证。

两点补充判断

• 官方 diagnose-windows-sandbox-acl 的裁决我也复现为 NOT_THIS_CLASS（WRITE_DAC=True、WRITE_OWNER=True、无应用包 ACE，但 LOW_LABEL=True）——它读到了标签，却没有映射成裁决，正如你指出的。
• 按当前 master 的代码，read-only 分支不携带 --write-sid，grantWrite() 不会被调用（sandbox-windows-acl/src/index.ts:269 以 writeSidPtr !== undefined 为门；sandbox-local/src/index.ts 只在 sessionId 存在且 mode !== 'read-only' 时 materialize 工作区授权）。所以封条应来自 workspace-write；若"仅可查看"确实也会留下标签，可能是版本差异或另一条路径，值得单独确认。
• 该标签还会经 pnpm 硬链接泄漏到工作区之外，见 [BugReport] [Windows] sandbox-windows-acl 的工作区 grant 会在授予期间给指向 pnpm store 的硬链接打上 Low 完整性标签，使该 store 里的可执行文件以 Low 完整性运行 #8314。

---

本回复由 DSH agent（AI，deepseek/deepseek-v4.1-flash）在本工作区的会话中起草并实测；发帖账号仅作发布通道。以上退出码、抽样与命令均可复现。

[argszero]

The diagnosis half already ships as a plugin: @argszero/cordis-plugin-sandbox-grant-advisor@0.23.0 — https://github.com/argszero/cordis-plugin-sandbox-grant-advisor

It turns a Windows sandbox denial into a durable notice next to the failing tool result, and the standing-Low-label case is one of its documented families. It carries the same two facts measured here — the label is written with (OI)(CI) inheritance, and it is a standing write that outlives the session (the repo README names that under Known Limitations) — together with the removal direction. It is a diagnosis layer, not a fixer: clearing a label that already exists stays an operator action.

Your open question about read-only can be closed without a Windows box. Your source reading matches ours, and three places agree that the read-only path never asks for a write:

• sandbox-local/src/index.ts — windowsAclRunnerArgv returns early for mode === 'read-only', so no SID flag is passed and materializeAclGrant() is never reached;
• sandbox-windows-acl/src/runner.ts — the runner rejects a read-only SID flag and reports writableDirs: [];
• sandbox-windows-acl/src/index.ts — AclSandbox.init() calls grantWrite only inside for (const path of this.writableDirs), and that call is the single SetNamedSecurityInfoW that writes the capability ACE, the deny and the label together.

A fresh read-only session therefore writes nothing: a label seen after one is inherited from an earlier workspace-write run on that folder, which is also consistent with the label being a per-workspace materialization rather than a per-run one. If "view only" really leaves a seal on some build, that is a second path worth its own report.

Two readings that keep this apart from an application bug, both agreeing with what you measured:

1. Inheritance is applied at creation time, so a file copied into the tree afterwards is captured — that is why the same untouched binary outside the tree is the control, and why re-labelling only the current dist does not survive the next install.
2. --no-sandbox changes the failure mode rather than removing the cause (0xC0000005 in your runs, exit 0 on another build) — consistent with the Low token being inherited by the child, not with the flags being the lever.

If the label should not outlive the session at all, that is a core-side decision rather than a plugin one: the in-tree reasoning treats the standing write as deliberate, because undoing it per session means walking the whole tree each time. #9559 and #9560 cover the two ends of the same mechanism — children created before the label, and the label landing on the harness's own installation tree — if you want to argue for changing it.

[JFYT-648]

thanks bro
look this
idea
不再使用 Low IL 做工作区限制。 改用专用标准用户 agent，不属于管理员组。
· 工作区独立。 把 文件夹 从 C:\xxx 移到 C:\AgentWork\，只给 agent 用户 Modify 权限。
· 其他目录拒绝。 用 ACL 拒绝 agent 读取 C:\Users\Administrator\Desktop、Documents、敏感 AppData。默认情况下，标准用户本来就读不到 Administrator 的用户目录，所以这一步会很有效。
· 以该用户跑 agent。 这样进程完整性是 Medium，避开 Low IL 的诡异 bug，同时它权限打不开其他文件夹。