codex-companion IPC pipe deadlocks mid-review when codex spawns stdout-heavy PowerShell commands on Windows

[lukaskucinski]

Environment

• codex plugin v1.0.4 (Claude Code marketplace install)
• Windows 10 Pro 10.0.19045
• Claude Code agent session, VS Code extension
• Codex invoked via node codex-companion.mjs adversarial-review --background --base main "<focus>"

Symptom

Codex adversarial-review job started successfully. Within ~14 seconds the broker's IPC channel went silent — updatedAt froze, progressPreview in status <job-id> stopped advancing, and the underlying .log file mtime froze a further ~46 seconds later. The job kept reporting state=running indefinitely. No completion event was ever emitted.

Reference: job ID review-mpbtwgbj-gswbux (Codex session 019e3d65-84c2-7e31-93bd-46c3f48942f7), broker updatedAt froze at 2026-05-18T23:22:13Z.

Log path: C:\Users\<user>\.claude\plugins\data\codex-openai-codex\state\<workspace>\jobs\review-mpbtwgbj-gswbux.log.

The last broker Progress: entries before the freeze were a series of PowerShell Get-Content -Path … commands. Hypothesis: one of those commands produced enough stdout to fill the IPC pipe buffer between the codex process and codex-companion.mjs broker, deadlocking subsequent writes.

Related: #329 is a similar "stuck on 1.0.4" symptom with less diagnostic context — may be the same root cause.

Reproduction (partial)

Hard to reproduce on demand — depends on codex deciding to read a large file via Get-Content mid-review. Triggers more reliably on Windows than Linux/macOS because PowerShell's Get-Content defaults serialize each line as a separate object and can produce larger-than-expected stdout for a given file.

Suggested fix direction

Buffer-drain on the IPC pipe between codex process and broker (use a non-blocking reader on the broker side, OR cap individual command stdout at the codex side). Confirming the actual root cause requires codex-side tracing — happy to add diagnostic logging on my end if useful.

Workaround in our orchestrator

We've added stall detection that fires when both broker progressPreview and log mtime have been frozen for ≥3 minutes, surfacing the deadlock to the user with a copy-pasteable Stop-Process recovery command — see https://github.com/lukaskucinski/clodex commit f0a5b5c. Useful as a client-side mitigation but not a root-cause fix.

Companion issue for the failed cancel fallback is filed separately (taskkill /PID mangled by Git Bash MSYS) — will cross-link once filed.

[lukaskucinski]

Cross-link: the cancel-fallback follow-on issue is now filed as #331 (taskkill /PID mangled by Git Bash MSYS on Windows). Both came from the same orchestrator run; the cancel issue is an independent bug that surfaces only when you try to recover from the deadlock described here.