[Bug] Desktop: 卷根 ACL 含包 SID 但缺 ALL APPLICATION PACKAGES 时启动即崩；自动更新后必现「双击无反应」

[renge1145141919810]

Windows 11，安装于 D:\。卷根 ACL 含 AppContainer 包 SID ACE、但缺 ALL
APPLICATION PACKAGES（S-1-15-2-1）ACE 时，桌面端启动即静默崩溃：无窗口、
无提示，双击没反应。自动更新后必现（更新文件继承坏 ACL 且未补授），重装无效。

环境

• Windows 11 家庭版 Build 26200
• 桌面端 0.2.0.2 / 0.2.0.3（Electron 44.7.0），安装路径 D:\deepseekherness

日志

以 --enable-logging 启动，stderr：

FATAL:electron\shell\browser\win\install_dir_access.cc:52] Sandboxed processes
cannot read D:\deepseekherness: its ACL has an entry for an AppContainer package
SID but none for ALL APPLICATION PACKAGES...

事件日志（每次一致）：Event 1000，Exception 0x80000003，fault offset 0x7356e49，
faulting module 为 exe 自身。

根因

Chromium 沙箱要求：安装目录 DACL 有包 SID ACE 时必须同时有 AAP ACE，否则
沙箱进程无法读取安装目录，主进程 FATAL 退出。更新器不补授该 ACE，故每次
更新后复发。

临时解决

icacls "<安装目录>" /grant *S-1-15-2-1:(OI)(CI)(RX) /T

执行后立即恢复正常。

建议

1. 安装器/更新器写入后补授 AAP ACE
2. 启动时预检 ACL，失败弹窗提示，而非静默崩溃
3. 疑与 [Desktop][Bug] Windows 沙箱的写入授权会给工作区目录打上可继承的 Low 完整性标签；当工作区是安装目录的上级目录时，会导致应用自身无法启动 #10448 属同类沙箱 ACL 问题

[PerryLink]

That FATAL is Chromium's install-directory access check. The condition it objects to is removable.

install_dir_access.cc fails when the install directory's DACL carries an AppContainer package SID ACE without the ALL APPLICATION PACKAGES (S-1-15-2-1) counterpart. Your reading of the update behaviour also matches the contract: an in-place update replaces files inside the existing directory and inherits the ACL it finds, and the Windows uninstaller removes app data rather than a parent-directory ACL (apps/desktop/README.md:264), so a reinstall cannot clear it.

The remove-the-stray-entry half is shipped: diagnose-windows-sandbox-acl (packages/sandbox/sandbox-windows-acl/README.md:78-80) deletes explicit S-1-15-2-* allow ACEs at their source, ancestor first, and repairs missing WRITE_DAC / WRITE_OWNER on the same chain. One unconfined run:

& '<skill-dir>\scripts\diagnose-windows-sandbox-acl.ps1' -Path '<install-dir>' -AllowRoot '<install-dir>' -Out '<recovery-dir>'

Because your volume root carries the entry, the effective scope may be D:\ rather than the install directory — run it on the path whose ACL actually contains the package SID, and keep -AllowRoot at or above it. Every DACL change is backed up, verified by re-reading, and printed with a rollback command.

Two honest limits. The script refuses reparse points and managed application trees, so it may decline an install directory; and the diagnostic exists to repair sandbox denials, so a refusal here is not a defect in it. If it refuses, the edit is the same one it would have made, done by hand after icacls D:\ /save.

The asset is present at the rc.3 tag (1f81c047) and master (22ddee3); I read the skill and script sources, I did not run them.