【bug】工作区内修改无法运行pwsh

[tl4508677-coder]

如图所示，dsh desktop使用【工作区内修改】无法正常运行pwsh以及cmd，甚至都无法查看非工作目录的文件。切换成【完全权限】后可以正常运行。同一台电脑的dsh web使用【工作区内修改】没有任何问题。怀疑是desktop的bug。求解决方法。

[argszero]

Same machine working under dsh web in workspace-write and failing under dsh desktop is a useful control — it is the one comparison that separates the two known producers of this shape, and it is the comparison the two most recent reports of it (#8990, #8991, #9186) could not make, because those machines only ran one app.

What the comparison says. Under workspace-write on Windows every command is started through the sandbox's restricted-token runner, and the runner is started as [process.execPath, runner.js]. In the packaged desktop process.execPath is the Electron executable, which is a GUI-subsystem program and owns no console; the confined child then has to create one for itself, and a restricted token can inherit a console but not create one — so the child is killed during initialization, before its entry point, which is what you see as "cannot run pwsh or cmd at all". dsh web runs the same runner from a real node.exe, which is a console-subsystem program and has a console to hand down. Same workspace, same mode, same command: the host binary is the variable (#8322, #8193).

That also explains the second half of your report — not being able to read files outside the workspace directory — as ordinary sandbox behaviour rather than part of the bug: workspace-write grants writes inside the workspace tree only, so reads outside it are expected to be refused, in both apps.

Ways out, in order of least surprise:

1. Run the same task from dsh web (already working for you), or launch the desktop's own runtime node directly instead of the Electron app — the packaged desktop ships one at resources/runtime/primary-runtime/dependencies/node/bin/node.exe.
2. Switching the session to read-only is not a reliable way out here. It goes through the same restricted runner started from the same host binary, so it changes what is granted, not who spawns the child; one recent report ([Bug][Windows] workspace-write 下 restricting 列表含 1 个 S-1-4 capability SID 即致任何子进程 0xC0000142 秒退 — 最小复现与精确定位（关联 #8991） #9186) does show read-only working while workspace-write dies on the same machine, but that machine was driven through the sandbox API from a node host, not from the packaged desktop app — so it is not evidence that read-only helps your case. Worth one try, not worth counting on.
3. danger-full-access does make the tools work, but by removing the sandbox from every shell call rather than repairing anything — treat it as confirmation of the diagnosis, not as a fix.

I maintain @argszero/cordis-plugin-sandbox-grant-advisor, which recognizes this failure at the tool-result seam and writes a durable advisory into the session naming the mode and the host — including this exact full-access-app-works / dsh web-works comparison as the check to run — since the harness itself reports it as a plain failing command with no sandbox framing.