Repository navigation
Codex sandbox shell commands fail with CreateProcessAsUserW 1312 on Windows — Store pwsh.exe cannot be spawned from Git Bash subprocess context #336
Description
Environment
- codex plugin v1.0.4 (Claude Code marketplace install)
- Windows 11 Home 10.0.26200
- Claude Code desktop app (Git Bash shell context)
- Codex invoked via `node codex-companion.mjs adversarial-review --base main`
- PowerShell 7.6.1 installed via Windows Store (WindowsApps stub)
- PowerShell 7.6.1 also installed as real MSI at `C:\Program Files\PowerShell\7\pwsh.exe`
Symptom
Every shell command the Codex GPT model attempts fails with exit code -1 and a `CreateProcessAsUserW failed: 1312` error. The companion script reports these as:
```
[codex] Running command: "C:\Users\achau\AppData\Local\Microsoft\WindowsApps\pwsh.exe" -Command 'git diff --stat'
[codex] Command failed: "...\pwsh.exe" -Command 'git diff --stat' (exit -1)
```
This means the Codex GPT model cannot execute any local git commands during the review, producing an `approve` verdict with the disclaimer:
"No defensible ship-blocking finding. Read-only git inspection was attempted, but the shell runner failed before executing commands."
The review is effectively a no-op on this configuration.
Root cause
The Codex GPT model explicitly generates `C:\Users<user>\AppData\Local\Microsoft\WindowsApps\pwsh.exe -Command '...'` as the command string for its shell tool calls. The Windows Store version of PowerShell (`WindowsApps\pwsh.exe`) is an activation stub — it cannot be spawned as a subprocess from a non-interactive context (such as from Git Bash or Node.js `child_process.spawnSync`). Windows returns error 1312 (`ERROR_NO_SUCH_LOGON_SESSION`) because Store app activation requires a desktop session context.
The real PowerShell MSI install at `C:\Program Files\PowerShell\7\pwsh.exe` IS spawnable from subprocesses — but the Codex model hardcodes the `WindowsApps` path regardless of what's in PATH.
Note: `process.env.SHELL` in the Claude Code / Git Bash context is `C:\Program Files\Git\bin\bash.exe`, so the `process.mjs` `shell: process.env.SHELL || true` fallback correctly picks up bash for the companion's own git calls. The problem is exclusively in the Codex GPT model's explicit choice of `WindowsApps\pwsh.exe` for its tool calls inside the app-server sandbox.
What was tried
- Installed real PowerShell 7.6.1 MSI (`C:\Program Files\PowerShell\7\pwsh.exe`) — same error, model still generates the Store path
- Set `SHELL=C:\Program Files\Git\bin\bash.exe` in project `.claude/settings.json` env — no effect on model-generated commands
- Set `CODEX_SHELL` env var — not respected by app-server
- Patched `process.mjs` `runCommand` to rewrite `pwsh.exe` calls to bash — companion's own git calls go through `process.mjs`, but the model's app-server tool calls do not; patch had no effect
- `winget upgrade Microsoft.PowerShell` — reports "no upgrade available" (Store version is treated as current)
Suggested fix
The Codex app-server on Windows should prefer `C:\Program Files\PowerShell\7\pwsh.exe` (or the value of `COMSPEC`/`SHELL`) over the `WindowsApps` stub when generating shell tool calls. Alternatively, the app-server could detect the `1312` error and retry with a fallback shell path.
Workaround
Use `elite-security-auditor` (Claude Code custom agent) as the adversarial review gate on this machine configuration. It reads files directly and does not depend on shell subprocess spawning.
Related
- codex-companion IPC pipe deadlocks mid-review when codex spawns stdout-heavy PowerShell commands on Windows #330 — different root cause (IPC pipe deadlock from PowerShell stdout overflow) but same surface symptom (Codex review returns no findings on Windows)
- Codex review no response all the time in claude code VS Code plugin #329 — "no response" symptom, possibly related
Activity
docs(exploration): Phase B — suminerProxy fork eval + upstream issue …
fix(upstream): Sprint 2 — openai#331 taskkill MSYS + openai#333 adver…
chore(release): v2.2.0 — daily-evolve pipeline + plugin auth discipli…
docs(exploration): Sprint 4-8 implementation guide — substrate critic…
pedronavf commentedon Jul 17, 2026
The problem is the App alias, a symbolic link that the App Store adds to have all the Store binaries in the PATH (you'll see a zero bytes pwsh.exe).
A workaround is removing that alias:
Windows + i (Settings) | Apps | Advanced app settings | App execution aliases: Find PowerShell and set it to OFF.
a951753abc commentedon Aug 26, 2026
Adding a data point from plugin v1.0.6 / codex-cli 0.149.1 on Windows 11 (
[windows] sandbox = "unelevated"), plus a second, independent failure mode we traced while diagnosing this.1. Confirming the Store/MSIX pwsh layer
With only the Store pwsh installed (
C:\Program Files\WindowsApps\Microsoft.PowerShell_7.6.5.0_x64__...), one adversarial-review job had 21 of 62 shell commands fail withexit -1within ~300ms; each failure matches a Storepwsh.exespawn record in~/.codex/.sandbox/sandbox.*.log. The model spent most of the turn retrying. Installing the MSI PowerShell 7 (and removing the Store package sopwshresolves toC:\Program Files\PowerShell\7\pwsh.exe) eliminates this layer — consistent with openai/codex#18937 and openai/codex#19550.2. Independent bug: job dies silently and stays
runningforeverThe same job then died with no
Turn completed/Final output, the companion process exited with code 0, and the job JSON still saysstatus: "running"with a dead PID. From the 1.0.6 sources the mechanism appears to be:turn/startRPC has already resolved, so it is no longer in the app-server client's pending-request map.captureTurn()then waits on a separatestate.completionpromise (scripts/lib/codex.mjs:559-606).handleExit()only rejects the RPC pending map (scripts/lib/app-server.mjs:163-176);state.completionis never rejected.runTrackedJob()(scripts/lib/tracked-jobs.mjs:142-202) never resolves or catches, so the job is never written ascompleted/failed.Evidence the two layers are independent: historical jobs here with up to 18
exit -1still completed fine, and two other stale-runningjobs had zero pwsh failures.status(scripts/lib/job-control.mjs:213-240) also only filters job JSON byqueued/running— no PID-liveness, broker-connectivity, or log-heartbeat check — so a stalerunningis indistinguishable from a live job.Suggestions:
captureTurn(), race turn completion against client/transport exit, rejecting with a transport-disconnected error sorunTrackedJob()can recordfailedwith a non-zero exit.status(or a supervisor) validate PID liveness (plus process start time, to avoid PID-reuse false positives) and a log heartbeat, and atomically mark dead jobsfailed.COMSPECover the WindowsApps stub, per the OP.docs(triage): v1.4.0 upstream comment drafts and status updates
CBEPX commentedon Sep 29, 2026
Fixed on the plugin side in CBEPX/codex-plugin-cc v1.4.1 (https://github.com/CBEPX/codex-plugin-cc/releases/tag/v1.4.1): the plugin no longer needs the Store
pwsh.exe. Its Windows process checks and kills run through the in-box Windows PowerShell 5.1, launched by absolute path (System32\WindowsPowerShell\v1.0\powershell.exe) with a clean environment. Shell commands that Codex's own sandbox runs are Codex's, not the plugin's, so I cannot say whether the 1312 error still appears there; a retest report would help.This is a fork release, not an upstream fix, so I'm leaving this issue open for the maintainers here.