Environment: Windows 10/11, codex-plugin-cc (installed via Claude Code plugin
marketplace), invoked through the codex:codex-rescue subagent -> codex-companion.mjs
I ran into three related issues while delegating a task from Claude Code to Codex
on Windows:
1. Sandbox helper fails before running any command
Running a task that needed to execute a PowerShell command failed immediately
with:
windows sandbox: helper_unknown_error: setup refresh had errors
No command was ever executed -- Codex returned the intended commands as plain
text instead, which is a reasonable fallback, but the underlying sandbox
execution path appears broken on this Windows machine.
2. cancel command mangles the /PID flag on Windows
When a job hung and I tried to cancel it via the companion script's cancel
subcommand, the underlying taskkill invocation failed with:
taskkill /PID 11848 /T /F: exit=1: Error: Argumento u opcion no valido - "C:/Program Files/Git/PID".
This looks like a Git-Bash/MSYS path-translation issue: /PID is being
interpreted as a POSIX path fragment and rewritten to a Windows path
(C:/Program Files/Git/PID) before reaching taskkill. Workaround: killing
the process directly via Stop-Process -Id <pid> in PowerShell instead of the
companion's own cancel command.
3. Hung jobs never transition out of "running" status
A job whose underlying Codex thread was confirmed gone (log line: Codex turn interrupt failed: thread not found: <threadId>) still shows "status": "running" in status --all --json more than 24 hours later. There doesn't
seem to be a timeout or reconciliation step that marks orphaned jobs as
failed/dead, so status --all accumulates zombie entries indefinitely.
Suggested fixes
- Investigate why the sandbox helper fails to initialize on Windows (possibly
related to how the sandbox is set up per-platform).
- Fix the
cancel command to avoid POSIX-style /PID flags when the
underlying shell is Git Bash/MSYS on Windows (e.g. use a stop-parsing
token, or invoke via cmd.exe /c explicitly, or use PowerShell's
Stop-Process instead of taskkill).
- Add a reconciliation check that detects "thread not found" and marks the job
as failed instead of leaving it "running" forever.
Environment: Windows 10/11, codex-plugin-cc (installed via Claude Code plugin
marketplace), invoked through the codex:codex-rescue subagent -> codex-companion.mjs
I ran into three related issues while delegating a task from Claude Code to Codex
on Windows:
1. Sandbox helper fails before running any command
Running a
taskthat needed to execute a PowerShell command failed immediatelywith:
No command was ever executed -- Codex returned the intended commands as plain
text instead, which is a reasonable fallback, but the underlying sandbox
execution path appears broken on this Windows machine.
2.
cancelcommand mangles the/PIDflag on WindowsWhen a job hung and I tried to cancel it via the companion script's
cancelsubcommand, the underlying
taskkillinvocation failed with:This looks like a Git-Bash/MSYS path-translation issue:
/PIDis beinginterpreted as a POSIX path fragment and rewritten to a Windows path
(
C:/Program Files/Git/PID) before reachingtaskkill. Workaround: killingthe process directly via
Stop-Process -Id <pid>in PowerShell instead of thecompanion's own cancel command.
3. Hung jobs never transition out of "running" status
A job whose underlying Codex thread was confirmed gone (log line:
Codex turn interrupt failed: thread not found: <threadId>) still shows"status": "running"instatus --all --jsonmore than 24 hours later. There doesn'tseem to be a timeout or reconciliation step that marks orphaned jobs as
failed/dead, so
status --allaccumulates zombie entries indefinitely.Suggested fixes
related to how the sandbox is set up per-platform).
cancelcommand to avoid POSIX-style/PIDflags when theunderlying shell is Git Bash/MSYS on Windows (e.g. use a stop-parsing
token, or invoke via
cmd.exe /cexplicitly, or use PowerShell'sStop-Processinstead oftaskkill).as failed instead of leaving it "running" forever.