Repository navigation
Closed as duplicate
Closed as duplicate
Copy link
Labels
duplicateThis issue or pull request already existsThis issue or pull request already exists
Description
Bug
Background tasks (/codex:rescue, /codex:task) can hang indefinitely when the Codex API stalls during response generation. There is no timeout mechanism to recover from this state.
Observed Behavior
- Task starts successfully, Codex reads files and runs commands (visible in log)
- After all tool calls complete, Codex enters response generation phase
- Log file stops updating — no new entries for 8+ minutes
- Task remains in
status: "running"forever result <job-id>returns"No job found"because it only queries completed/failed/cancelled jobscancel <job-id>fails because the OS process has already exited (but the job record was never updated)
Root Cause (suspected)
Two issues compound:
1. No response timeout
tracked-jobs.mjs runTrackedJob awaits the Codex API call without a timeout. If the API stalls during generation, the job hangs indefinitely.
2. Job state not updated on process exit
When the Codex process exits unexpectedly (or the API connection drops), the job record in the state file is never transitioned from running to failed. This leaves orphaned running jobs that:
- Can't be queried via
result(which filters for completed/failed/cancelled only) - Can't be cancelled (process already gone)
- Block
task-resume-candidatefrom working correctly
Expected Behavior
- Tasks should have a configurable timeout (e.g., 5 minutes of no activity)
- If the process exits without updating job state, the companion should detect orphaned jobs and mark them as
failed resultshould provide partial output for timed-out or orphaned jobs
Environment
- Windows 11 Pro 10.0.26200
- Node.js (latest)
- codex-plugin-cc 1.0.1
- Claude Code (latest)
- Codex CLI 0.117.0
Reproduction
- Run a
/codex:rescuetask with a complex, multi-file review prompt - Wait for Codex to complete its tool calls (file reads, greps)
- Observe the log file — after the last command completes, no further output appears
status --jsonshows the task asrunningwith increasing elapsed time- The task never completes
Log excerpt
[06:29:06] Assistant message: キャンセル処理は一箇所だけ直しても意味がない場合があります...
[06:29:06] Running command: powershell -Command 'Get-Content Goudy....'
[06:29:07] Command completed (exit 0)
[06:29:07] Command completed (exit 0)
[06:29:07] Command completed (exit 0)
[06:29:07] Command completed (exit 0)
— (no further log entries for 8+ minutes, task stays "running") —
Note
This was observed after locally patching the spawn codex ENOENT issue (#32 / #46). The task successfully starts and runs commands, but hangs during the final response generation.
Reacted by Dmitry Yuhanov and axisrow
Metadata
Metadata
Assignees
Labels
duplicateThis issue or pull request already existsThis issue or pull request already exists
Activity
DmitriyYukhanov commentedon Apr 16, 2026
Exactly the same issue, making codex plugin completely unusable.
amit777 commentedon Apr 18, 2026
been having this issue too on 1.0.3. occasionally it seems to work. Most times in hangs. I just type "have codex review your work". Possibly related to #234
fix: reconcile stale 'running' jobs when tracked PID is dead
fix: reconcile stale 'running' jobs when tracked PID is dead
feat(security+watchdog): manual port of upstream PR openai#312 / open…
docs: add OSS governance artifacts and PR-based contribution workflow (…
fix(grok): make job-state CAS atomic to stop cancel/running clobber r…
axisrow commentedon Jul 20, 2026
+1 — hit this concretely. Running /codex:rescue from a Claude Code session, if Codex CLI can't reach the OpenAI API (network down, DNS misconfigured), the companion hangs forever on 'await state.completion' in captureTurn. No turn-level timeout, no abort. The rejectCompletion in the turn-capture state is dead code — zero call sites. The host's external timeout eventually SIGKILLs the process with no output. PR #376 (@russjhammond) addresses exactly this and looks like the right fix.
feat: turn-level timeout — bound Codex turn await (port from openai#376…
dkundel-openai commentedon Aug 11, 2026
Duplicate of #520.