@PakAbhishek

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\PowerShell7円\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\PowerShell7円\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

1. Installed real PowerShell 7.6.1 MSI (`C:\Program Files\PowerShell7円\pwsh.exe`) — same error, model still generates the Store path
2. Set `SHELL=C:\Program Files\Git\bin\bash.exe` in project `.claude/settings.json` env — no effect on model-generated commands
3. Set `CODEX_SHELL` env var — not respected by app-server
4. 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
5. `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\PowerShell7円\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