Windows: shell tool-calls inside Codex turn fail with 'CreateProcessAsUserW failed: 1920' on plugin v1.0.4

Environment

• OS: Windows 11 Pro 10.0.26100
• Node: v24.14.0
• npm: 11.9.0
• Codex CLI: 0.128.0
• Plugin: v1.0.4 (cache ~/.claude/plugins/cache/openai-codex/codex/1.0.4/)
• Shell in Claude Code: Git Bash (MSYS2 / MINGW64)
• ~/.codex/config.toml:

  model = "gpt-5.5"
  
  [windows]
  sandbox = "elevated"
  

Summary

Plugin v1.0.4 starts the Codex thread successfully (auth check ✅, setup ✅, app-server connect ✅, final-output returns), but shell-tool-calls inside the Codex turn fail before process start with CreateProcessAsUserW failed: 1920 (Windows token error) instead of running. The final output then explains "Shell access was blocked, I could not run X".

This is different from #277 (background-hang) — the Codex process does NOT hang, it returns final output promptly. It's also different from #57 (sandbox policy block) — the error is not "blocked by policy", it's a Windows-level token-creation failure (1920 = ERROR_NO_TRACKING_SERVICE).

Reproduce Recipe

1. Fresh Claude Code session on Windows 11 with Plugin v1.0.4 enabled
2. /codex:setup → reports ready: true
3. /codex:rescue with any task that needs disk-read (e.g. "review file X")
4. Codex thread starts, reasoning happens, final output returns
5. Final output contains: "Shell access to inspect the working tree was blocked"
6. Plugin job-log under ~/.claude/plugins/cache/openai-codex/codex/1.0.4/jobs/<run-id>/turn.log shows:

   shell tool error: CreateProcessAsUserW failed: 1920
   

   Plus separately:

   pwsh.exe exit -1
   

   for tools that try to invoke PowerShell.

Diagnostic Notes

Two contributing factors observed

Factor A — WindowsApps pwsh.exe is a 0-byte App-Execution-Alias stub

C:\Users\<user>\AppData\Local\Microsoft\WindowsApps\pwsh.exe is a 0-byte reparse-point that opens the MS-Store-install dialog when invoked interactively. In non-interactive sandbox contexts (Plugin's app-server tool-call path) it returns exit -1 immediately. If real PowerShell 7 is not installed, this stub is the first pwsh.exe in PATH.

Fix on user side: winget install --id Microsoft.PowerShell --accept-source-agreements --accept-package-agreements. After install C:\Program Files\PowerShell\7\pwsh.exe becomes the first match. Diagnose via where.exe pwsh (NOT where pwsh — the PowerShell builtin only shows the first hit).

Factor B — Plugin enforces approvalPolicy: never + sandbox: read-only for task-threads

In the Plugin's task-thread launch path, the app-server thread/start RPC is called with hardcoded approvalPolicy: never and sandbox: read-only, regardless of the user's ~/.codex/config.toml [windows] sandbox = "elevated" setting. This means even after fixing Factor A (real PowerShell 7 installed), shell-tool-calls inside the Codex-turn use a more restrictive sandbox than the direct CLI path.

Combined effect: the CreateProcessAsUserW failed: 1920 error appears to be the Windows-token-API rejecting a process-spawn under the read-only sandbox restriction when the path resolves to the WindowsApps stub. The 1920 = ERROR_NO_TRACKING_SERVICE strongly suggests a token-related path: the spawn syscall succeeds at one layer but the Windows kernel rejects the elevated-token-context combination.

Bisection

Plugin	CLI	Symptom
v1.0.2	0.128.0	env-strip + Windows-SHELL bugs (now fixed in 1.0.4 per #138 + #160)
v1.0.4	0.128.0	CreateProcessAsUserW failed: 1920 for tool-calls inside Codex-turn

6 fresh /codex:rescue attempts across 5 separate Claude-Code sessions over 5 calendar days. All fail at the same point. Restart of Claude Code, restart of computer, fresh git-clone — none changes the symptom.

Expected

Tool-calls inside the Codex-turn run with the same sandbox policy the user configured in ~/.codex/config.toml (in our case [windows] sandbox = "elevated"), or at least with a sandbox policy that allows read-only PowerShell commands.

Suggested Fix

Same options as in #57:

• Option A: Change Plugin's thread/start call to pass through user's ~/.codex/config.toml [windows] sandbox setting instead of hardcoding read-only.
• Option B: Have the Plugin's task-thread launch use approvalPolicy: on-failure instead of never, so failures surface to the user instead of silently being swallowed.
• Option C: At minimum, fall back gracefully when pwsh.exe resolves to the WindowsApps stub — detect via file-size==0 / reparse-point check before spawn.

Cross-references

• Related: #57 (sandbox-policy block, same layer, different symptom)
• Related: #277 (v1.0.4 background-hang, identical environment, different symptom class)
• Possibly related: #287 (spawn ENOENT, but pre-codex-turn)

Start at the task-thread launch path and its app-server thread/start RPC, then compare its approval and sandbox settings with ~/.codex/config.toml and the direct CLI behavior. Reproduce on Windows 11 with the listed v1.0.4 environment, inspect jobs/<run-id>/turn.log, and run where.exe pwsh; done means shell tool calls work or the failure is surfaced clearly under the supported policy.