这是什么问题？折腾疯了，命令执行不了，毁灭吧：“前台和后台 pwsh 又都返回 spawn EPERM，因此修复后的插件测试还没有执行结果”

[aesopcmc]

[argszero]

"spawn EPERM" here is a documented boundary of the Windows ACL restricted-token backend, not a misconfiguration — and what you describe ("the fixed plugin's test run still has no result") is exactly the shape #3193 reports: a suite that looks like it failed when in fact no test body ever started.

The mechanism is written down in the backend's own README, under Limits — packages/sandbox/sandbox-windows-acl/README.md:

Piped stdio capture is impossible for confined grandchildren — libuv's pipe stdio uses named pipes, whose client-end open requests write access no restricting SID is granted (the Win32 layer's default SD template, not the token default DACL), so spawn(..., { stdio: 'pipe' }) inside a confined process fails with EPERM; inherited and ignored stdio spawns work, and anonymous pipes (PowerShell pipelines) work because the restricted token's default DACL carries a full-access restricting-SID ACE.

So who is spawning is what decides it. A pwsh/node process inside the sandbox that spawns a child with piped stdio gets EPERM; the same spawn with stdio: 'inherit' or 'ignore' succeeds, and a PowerShell pipeline succeeds. npm test is the archetype of the failing case: node spawns grandchildren and captures their output through pipes, so under confinement each of them dies before its body runs.

Two things worth separating before you spend more time on it:

1. This is not the runner failing to start. When the sandbox's own launcher fails you get the runner's own line (windows-acl-run: …) plus exit 127 — a different shape, and it fails before the confined child exists. Bare spawn EPERM at this layer is the boundary above, i.e. the failure is inside the confined child.
2. The sandbox mode does not change this one. The README states the boundary with no read-only / workspace-write qualifier — unlike the 0xC0000142 signature in #9548, which is mode- and carrier-sensitive. Note also that the backend's setTokenDefaultDaclGrant (which merges a single full-access restricting-SID ACE into the token's default DACL) does not reach this: the README says the missing write access comes from the Win32 layer's default SD template for named pipes, not the token default DACL. Please don't loosen or remove that ACE while chasing this — it takes every piped grandchild spawn down with it.

Practical options: run the test command where the spawning process is not confined (an ordinary shell outside the sandbox), or make the confined side use inherited/ignored stdio instead of stdio: 'pipe'. There is no plugin-layer fix for the boundary itself — the primitive that would have to change is the backend's token/pipe policy, which is core, not a mount.

If you want a firmer answer than "matches the documented boundary", please paste the text of the output (a screenshot can't be quoted or searched), plus harness version, profile, sandbox mode and the exact command. With the windows-acl-run: prefix present or absent, runner-side and child-side are immediately distinguishable.