[Bug][Windows] MSYS2/Git Bash 无法在 ACL 沙箱下运行：couldn't create signal pipe, Win32 error 5（cmd/pwsh 同沙箱正常）

[fangwen9527]

现象

同一个 Windows ACL 沙箱 runner、同一个 --mode read-only、同一个工作区，只换被执行的程序：

被执行程序	实测输出	退出码
cmd.exe /c "echo cmd-ok"	cmd-ok	0
pwsh -NoLogo -NoProfile -Command "Write-Output pwsh-ok"	pwsh-ok	0
D:\Git\bin\bash.exe -c "echo bash-ok"	0 [main] bash (32652) D:\Git\bin\..\usr\bin\bash.exe: *** fatal error - couldn't create signal pipe, Win32 error 5	-1073741502 = 0xC0000142

⇒ 受限令牌下 MSYS2 运行时创建不了自己的信号管道，bash 在启动阶段就崩。
与 --temp / --workspace 有没有给无关，也不是环境变量问题（同一条命令在沙箱外跑完全正常）。

复现

$env:ELECTRON_RUN_AS_NODE = '1'   # 先规避另一个独立问题（runner 的启动方式，见同批另一帖）
$exe    = 'D:\deepseekharness\DeepSeek Harness.exe'
$runner = 'D:\deepseekharness\resources\app.asar\dsh\node_modules\@deepseek-ai\dsh-sandbox-windows-acl\lib\runner.js'
$ws = '<任一工作区>'

& $exe $runner --workspace $ws --temp $env:TEMP --mode read-only -- cmd.exe /c "echo cmd-ok"
& $exe $runner --workspace $ws --temp $env:TEMP --mode read-only -- '<pwsh 路径>' -NoLogo -NoProfile -Command "Write-Output pwsh-ok"
& $exe $runner --workspace $ws --temp $env:TEMP --mode read-only -- 'D:\Git\bin\bash.exe' -c 'echo bash-ok'

影响

• 任何在受限策略下调用 Git Bash / MSYS2 程序的下游（工具、插件）都会失败；
• DSH 自带 tool-bash 在 win32 是 disabled（@deepseek-ai/dsh-base/cordis.patch.yml:266-268，bash-sandbox 同样 disabled，见 :234-236），
  所以这条组合在上游很可能从未被覆盖过。

建议（任选）

1. 若可行：为受限令牌下的 runner 放行 MSYS 所需的命名管道创建；
2. 否则：在文档 / tool-bash 的 README 里明确写「Windows 沙箱下不支持 MSYS/Git Bash」，让下游能据此做降级；
3. 或考虑在受限策略下提供不依赖 MSYS 的 bash 方案（默认关闭、文档化）。

背景（怎么撞上的，可略）

一个把模型侧终端换成 Git Bash 的第三方插件，在接管前先跑一条自检命令；受限会话下自检失败 ⇒ 插件选择「不接管、保持 PowerShell」
（即宁可让位，也不把会话的 shell 打死）。顺着「为什么是零输出」这条线索，才定位到本贴与 runner 启动方式那个问题。

[argszero]

A third-party plugin now recognizes this exit code at the tool layer and names which of the two measured producers it is: @argszero/cordis-plugin-sandbox-grant-advisor@0.6.0 (source).

Usage — mount it in the profile with the shipped patch:

- insert:
    - id: sandbox-grant-advisor
      name: '@argszero/cordis-plugin-sandbox-grant-advisor'

Relation to this report. Your table is the second producer this family was built around, and it is the one a model can act on without any upstream change: the MSYS2 / Git-Bash runtime cannot create the pipe it uses for signals under the restricted token, so bash.exe aborts in the loader phase while cmd.exe and pwsh return 0 in the same workspace under the same mode. The plugin watches tools/post-execute and reads ToolExecutionSuccess.value, the shell tools' own canonical foreground projection, so the code arrives as the 32-bit integer (-1073741502, or 0xC0000142 in your unsigned spelling) rather than as text, and the couldn't create signal pipe, Win32 error 5 line your reporter captured stays evidence rather than becoming the trigger.

The advisory is delivered once per agent, only under a confining mode (under danger-full-access, or when no sandboxPolicy resolves, it withholds and says so once in the host log rather than guessing), and it states the class first: the loader terminated the process while its native images were loading — before the entry point — which is why the output is empty and why retrying the identical call cannot help. It then names this producer with the observations you supplied, and the one conversion it hands back is the one that needs no upstream fix: write the same work as a PowerShell or cmd command and continue, do not retry the MSYS2 program.

Two honest limits, since your suggestion 1 asks for the opposite. The plugin cannot relax the token — it never touches the sandbox's permissions, spawns nothing and sets no environment, so if the named pipe can be allowed for the restricted token that is an upstream change and this text does not pretend otherwise (it says so and does not offer danger-full-access as a substitute). And it agrees with you on coverage: because tool-bash and bash-sandbox are disabled on win32, the plugin's own composition has no way around this either — the advisory exists so the failure stops being silent, not so it stops happening.

Your session's choice — fall back to PowerShell instead of taking the terminal over and killing it — is exactly the behaviour this advisory is written to produce.