[问题] 构建时沙箱拦了 vcpkg 的写入，但 cmake 直接挂死不报错，排查了半天

[yiman0919]

在 DSH 的 pwsh 里跑正常的构建命令：

cmd /c "vcvars64.bat && cmake --build cmake-build-debug --target all -j 30"
结果 ninja 打印一句就没动静了：

[0/2] Re-checking globbed directories...
然后进程就一直挂着，cmake 的 CPU 长期是 0，既不退出也不报错。一开始我以为是命令没跑起来，来回试了好几次。中间有一次侥幸在前台跑到了错误点，报的是这种：

-- Running vcpkg install
write_contents_and_dirs("C:\src\vcpkg\buildtrees\0.vcpkg_dep_info.cmake"): permission denied
-- Running vcpkg install - failed
-- Configuring incomplete, errors occurred!
CMake Error at C:/src/vcpkg/scripts/buildsystems/vcpkg.cmake:953 (message):
vcpkg install failed. See logs for more information:
cmake-build-debug\vcpkg-manifest-install.log

因为项目中 CMake 用了 file(GLOB_RECURSE ... CONFIGURE_DEPENDS)，我这次新增了几个源文件，所以每次 ninja 构建都会触发 cmake 重新配置。而项目是 vcpkg manifest 模式，每次配置都会跑一遍 vcpkg install，哪怕包都装好了，它也要去更新 C:\src\vcpkg\buildtrees\ 下的状态文件 —— 这个目录在 workspace 之外。

DSH 的 pwsh 默认是 workspace-write 沙箱，写不进去。但 vcpkg/cmake 被拒之后不是快速失败，而是卡在那里等，ninja 也一起卡住，上面那个 permission denied 的错误在后台任务里完全看不到，输出全被缓冲吞了。最后我是靠 Get-Process 看 CPU 才定位到是 cmake 卡在重配置。

手动给我这个会话开了 danger-full-access 之后，同一条命令直接跑通，日志长这样：

[0/2] Re-checking globbed directories...
-- Running vcpkg install
The following packages are already installed: ...
All requested installations completed successfully in: 805 us
-- Running vcpkg install - done
-- Configuring done (12.9s)
-- Generating done (2.3s)
[6/7] Linking CXX executable xxx.exe
普通终端/IDE 没这个问题，就是因为我们平时对 C:\src\vcpkg 有完整写权限。

我建议沙箱拦截 workspace 之外的写入时，能不能直接给个明确的报错（比如 [sandbox: file access denied]）让命令快速失败？现在这种"挂着不动"太误导人了，错误还藏在日志文件里。
后台任务的输出建议实时刷新，别把错误全缓冲起来，长任务看着像没运行。
构建类命令（CMake/vcpkg 这种本来就要碰工作区外路径的）是不是该给个更合理的默认权限，或者在文档里提醒一下怎么配。

[PerryLink]

先说结论：这是策略按设计生效，不是沙箱故障。C:\src\vcpkg\buildtrees 这个路径不在本次调用的任何可写面里。

可写面到底有哪些

在 workspace-write 下只有两处：

1. 工作区根 —— 授权方式是按工作区路径确定性派生一个 SID、在根上落一条可继承的常驻 ACE（packages/sandbox/sandbox-local/src/index.ts:395-414 的 materializeAclGrant，:397 派生 SID、:401 的 grant.add(workspaceRoot, true)）；
2. 每个「会话 × 工作区」对一个随机私有临时目录 —— :418 的 mkdtempSync(join(tmpdir(), 'dsh-'))，其 TMP/TEMP 会在 spawn 前被改写到那里。

C:\src\vcpkg 两处都不在，所以你看到的 permission denied 是预期结果。这也是为什么手动开 danger-full-access 后同一条命令直接跑通。

为什么后台完全看不到「拒绝」标记

这里有个退出码门槛，值得说清楚。拒绝判定是「退出码非零 且 stderr 命中该后端的拒绝方言」两个条件同时成立：

• 方言表：packages/sandbox/sandbox-local/src/index.ts:205-213，其中 'windows-acl' = ['access is denied', 'access to the path', 'permission denied', 'operation not permitted']。vcpkg 那句 write_contents_and_dirs("C:\src\vcpkg\buildtrees\0.vcpkg_dep_info.cmake"): permission denied 确实命中。
• 判定函数：packages/shell/pwsh-sandbox/src/helpers.ts:115-119 —— if (exitCode === null || exitCode === 0) return false，然后才看 stderr 子串。

所以标记不出现，只需要其中一个条件不满足。你这次最直接的一层是：

1. 那次调用没有正常结算出退出码 —— ninja 那一句之后进程既不退出也不报错，你最后是靠 Get-Process 看 CPU 才定位到它卡在重配置。进程挂着/被杀 ⇒ exitCode 为 null ⇒ 上判定的第一步 if (exitCode === null || exitCode === 0) return false 就直接返回了，根本不会去看 stderr。至于 vcpkg 那行 permission denied 当时有没有进入工具层收集的 stderr，从你贴的内容我无法判断（CMake 自己的报错里给出 vcpkg-manifest-install.log 只说明另有一份日志，不等于前台 stderr 里没有）；你说「中间有一次侥幸在前台跑到了错误点」，那一次如果命令正常结算，按上表应能命中方言——所以更值得看的是那一次的 exitCode 与 stderr 原文。

而且沙箱这一侧不会给你超时兜底：sandbox-local 的 probeTimeoutMs（默认 5000）只用于 runner 候选的功能探测，不施加在受限命令本身上。所以「挂着不动」是这条链的真实终点，不是我们没等到。

下次怎么把它变成可见

# 1) 把那次调用的输出完整落盘（拒绝行会被 stderr 带出来）
cmd /c "vcvars64.bat && cmake --build cmake-build-debug --target all -j 30" 2>&1 | Tee-Object build.log

# 2) 或者先把 vcpkg 这一步单独暴露出来，不带 ninja
cmake --preset <你的 preset>       # 只 configure，让 vcpkg install 的失败直接冒到前台

# 3) 直接读它自己写的日志
Get-Content cmake-build-debug\vcpkg-manifest-install.log -Tail 40

修法（按推荐度）

1. 把 vcpkg root 挪进工作区（或至少让 buildtrees 落在工作区内）—— 一次到位，之后不需要任何提权，长期跑构建也不打扰你。
2. 需要它留在 C:\src\vcpkg 时，对这一次调用显式升级到 danger-full-access（sandbox_permissions + justification，用户批准一次，只对这次调用生效）。构建类命令本来就要写工作区外的路径，这是当前词汇表里唯一的那档开关。
3. 如果你不想每次审批，把会话默认模式切到 danger-full-access —— 代价是整个会话失去文件写入约束，请按你的环境判断。

关于你提的三条建议，我的看法：

• 「被拦时直接给明确的 [sandbox: file access denied] 让命令快速失败」—— 这个标记机制已经存在（就是上面那套方言判定），它没出现是因为这次调用没结算出非零退出码（挂住的进程没有退出码），判定第一步就 false 了。所以真正值得提的诉求不是「加标记」，而是「加一个不依赖子进程退出码与 stderr 的兜底路径」：例如被 ACL 拒掉后把拒绝事件按调用记录上报，而不是只靠事后扫 stderr。
• 「后台任务输出实时刷新」—— 这条和沙箱无关，是后台任务的输出呈现问题，值得单独反馈。
• 「构建类命令给更宽的默认权限」—— 这是设计取舍（默认更宽会让所有构建命令默认拿到工作区外写权限），我不替官方表态；就现状而言，第 1 条修法（挪进工作区）比放宽默认值更划算。

一个我们没法验的点：这台机器上没有 vcpkg、没有 cmake 工程，所以「为什么 CMake 是挂住而不是快速失败」这一层我只能给出推测 —— 可能与 file(GLOB_RECURSE ... CONFIGURE_DEPENDS) 每次触发重配置、而 vcpkg 的失败输出被缓冲/转写有关，但我没有实测；同理，「那行 permission denied 当时在不在前台 stderr 里」我也无法从你贴的内容判断。你可以用上面第 1、2 步验证：如果 tee 到 build.log 里能看到那行 permission denied，说明它只是被缓冲了；如果单独跑 cmake --preset 反而立刻报错（且退出码非零），那就说明挂住确实发生在 ninja 与 CMake 的交互里。

如果这条解释解决了你的问题，可以把它标为 answer，方便后面在 DSH 里跑 CMake/vcpkg 构建的人找到。