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
Environment
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:
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
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