1. src/node-host/exec-policy.test.ts, line 67-74 (link)

   Stale assertion will fail after message change

   The .toContain("Windows shell wrappers like cmd.exe /c require approval") assertion no longer matches because exec-policy.ts line 38-39 now inserts " or powershell -Command" between "cmd.exe /c" and " require approval", breaking the substring match. This test will fail as written.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: src/node-host/exec-policy.test.ts
   Line: 67-74
   
   Comment:
   **Stale assertion will fail after message change**
   
   The `.toContain("Windows shell wrappers like cmd.exe /c require approval")` assertion no longer matches because `exec-policy.ts` line 38-39 now inserts `" or powershell -Command"` between `"cmd.exe /c"` and `" require approval"`, breaking the substring match. This test will fail as written.
   
   
   
   How can I resolve this? If you propose a fix, please make it concise.

2. src/node-host/exec-policy.ts, line 61 (link)

   cmdInvocation is now an unused parameter

   After dropping params.cmdInvocation from the windowsShellWrapperBlocked expression, this required parameter has no effect on the function's output. If the intent is to preserve the public API surface (callers still populate it), add a brief comment explaining that; otherwise remove it and update call sites to avoid dead code and potential lint warnings from no-unused-vars.

   Prompt To Fix With AI

   This is a comment left during a code review.
   Path: src/node-host/exec-policy.ts
   Line: 61
   
   Comment:
   **`cmdInvocation` is now an unused parameter**
   
   After dropping `params.cmdInvocation` from the `windowsShellWrapperBlocked` expression, this required parameter has no effect on the function's output. If the intent is to preserve the public API surface (callers still populate it), add a brief comment explaining that; otherwise remove it and update call sites to avoid dead code and potential lint warnings from `no-unused-vars`.
   
   How can I resolve this? If you propose a fix, please make it concise.

Best possible solution:

Land the prepared fail-closed Windows shell-wrapper policy after adding redacted real runtime proof and letting the exact-head CI complete cleanly.

Do we have a high-confidence way to reproduce the issue?

Yes. Current main is source-reproducible by evaluating allowlist policy with isWindows=true, shellWrapperInvocation=true, and cmdInvocation=false; the guard still requires cmdInvocation today, so the PowerShell wrapper path is not blocked there.

Is this the best way to solve the issue?

Yes for the code direction. The prepared head is narrow and aligns policy, denial copy, docs, changelog, and regression coverage, but merge should wait for real behavior proof and completed CI.

What I checked:

• Current main guard is cmd-specific: Current main only sets windowsShellWrapperBlocked when security is allowlist, shellWrapperInvocation is true, isWindows is true, and cmdInvocation is true, so a PowerShell wrapper path with cmdInvocation=false is not fail-closed by this policy. (src/node-host/exec-policy.ts:68, 86a9b3fcb1c0)
• PowerShell wrappers are recognized upstream: The shell-wrapper resolver includes powershell and pwsh wrappers and extracts PowerShell inline commands through POWERSHELL_INLINE_COMMAND_FLAGS, so the policy can receive shellWrapperInvocation=true for non-cmd Windows wrappers. (src/infra/shell-wrapper-resolution.ts:20, 86a9b3fcb1c0)
• Invoke path separates wrapper and cmd facts: The invoke path derives cmdInvocation from isCmdExeInvocation but passes shellWrapperInvocation from parsed.shellPayload, which supports the current-main source reproduction with cmdInvocation=false and shellWrapperInvocation=true. (src/node-host/invoke-system-run.ts:424, 86a9b3fcb1c0)
• Prepared head broadens the guard: The prepared head changes windowsShellWrapperBlocked to depend on allowlist security, shellWrapperInvocation, and isWindows, removing the cmdInvocation requirement while preserving POSIX behavior comments. (src/node-host/exec-policy.ts:68, 3baf42a36bcd)
• Prepared head adds regression coverage: The prepared head updates the Windows denial-copy assertion and adds a PowerShell wrapper policy test with isWindows=true, cmdInvocation=false, and shellWrapperInvocation=true. (src/node-host/exec-policy.test.ts:150, 3baf42a36bcd)
• Prepared head updates docs and changelog: The prepared head updates node docs/troubleshooting to mention powershell/pwsh wrapper approval and adds the required user-facing changelog fix entry with contributor attribution. (CHANGELOG.md:190, 3baf42a36bcd)

Likely related people:

• steipete: Recent commits touched exec policy and invoke routing, including shell-wrapper allowlist security hardening and node-host export refactors around this surface. (role: recent maintainer and security-policy owner; confidence: high; commits: 3f0b9dbb36c8, 076fa5eae6e1, bd0e10a2f68f; files: src/node-host/exec-policy.ts, src/node-host/invoke-system-run.ts)
• ngutman: Authored the recent fix that aligned node shell allowlist wrappers, directly adjacent to this PR’s policy behavior. (role: prior exec allowlist contributor; confidence: medium; commits: d008e2d01529; files: src/node-host/exec-policy.ts)
• vincentkoc: Authored the recent remote approval regression fix touching exec policy semantics and has recent node-doc maintenance history. (role: exec approval and node docs maintainer; confidence: medium; commits: 2d53ffdec1da, d71518b1eb9d; files: src/node-host/exec-policy.ts, docs/nodes/troubleshooting.md)
• pgondhi987: Authored recent shell-wrapper parsing and approval-binding hardening in the shared shell-wrapper resolver used by this policy path. (role: adjacent shell-wrapper hardening contributor; confidence: medium; commits: fc065b2693bf; files: src/infra/shell-wrapper-resolution.ts)

Remaining risk / open question:

• The PR still lacks after-fix real behavior proof from a Windows node/exec setup; the exact head’s Real behavior proof check is failing.
• Several CI check runs for the prepared head were still queued during this review, so merge should wait for the exact head to finish required checks.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 86a9b3fcb1c0.