›_ Codex Issues
Codex Issues / #34905

Codex App crashes when reopening a long-running task and incorrectly keeps it marked as running

Open 💬 3 comments Opened Jul 23, 2026 by Mr-D-Joe
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of the Codex App are you using (From “About Codex” dialog)?

26.715.72359 (Build 5718)

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

The Codex Desktop App enters an unrecoverable state after a long-running task.

Observed behavior:

  1. Codex crashes while a task is running.
  2. After restarting, the app reports that the task is still running.
  3. Opening the running task immediately returns to the crash screen.
  4. "Retry" returns to the start screen, but the task is still shown as running.
  5. Reopening the task crashes again.
  6. The only way to recover the application is to force quit it with Cmd+Q.
  7. This interrupts the running work and no normal recovery path is available.

Additional observations:

  • This has happened multiple times with the same task.
  • The task is unusually long-running and contains many recovery cycles and subagent executions.
  • During investigation we observed cases where the UI state and the actual execution state appeared to diverge:
  • the UI displayed "Agent finished",
  • later evidence showed additional work had still been produced,
  • and at one point user messages could no longer be injected into the running task ("Try sending this message from the queue again").

Therefore it is currently unclear whether the failure originates in:

  • task recovery,
  • session reconstruction,
  • lifecycle synchronization,
  • event/API transport,
  • client message queue,
  • UI state reconciliation,
  • or an interaction between those layers.

The important point is that the application becomes permanently stuck in a recovery loop. The user cannot reopen, terminate, or recover the task through the UI. Force quitting the application is the only available escape.

What steps can reproduce the bug?

  1. Start a long-running Codex task that runs for an extended period with multiple subagent executions, recovery cycles, and context compressions.
  2. Continue working until the Codex App crashes.
  3. Restart the Codex App.
  4. Observe that the previous task is still shown as "running".
  5. Open that running task.
  6. The app immediately returns to the crash screen.
  7. Selecting "Retry" returns to the home screen, but the task is still marked as running.
  8. Reopening the task reproduces the same crash.
  9. The only escape is to force quit the application (Cmd+Q).

This has happened multiple times with the same long-running task.

What is the expected behavior?

The application should not crash when running or reopening a long-running task.

If an unexpected crash does occur, Codex should recover safely and consistently:

  • restore the task successfully, or clearly mark it as interrupted;
  • preserve all recoverable work;
  • keep the task accessible;
  • avoid any permanent recovery loop;
  • allow the user to terminate or restart the task cleanly;
  • keep the displayed UI state consistent with the actual execution state.

Additional information

Additional observations:

  • Codex version: 26.715.72359 (Build 5718)
  • macOS: Darwin 25.5.0 arm64
  • ChatGPT Plus subscription

The affected task was unusually long-running.

Observed task characteristics:

  • approximately 81.5 MB local task data
  • approximately 20,997 records
  • approximately 35 context compressions
  • largest individual record approximately 3.33 MB

I cannot prove that task size is the root cause, but the crashes have only occurred on this unusually large task.

I provide screenshots.

<img width="387" height="138" alt="Image" src="https://github.com/user-attachments/assets/dc9de770-7bab-4e95-8c4d-51d6186617c8" />
<img width="803" height="655" alt="Image" src="https://github.com/user-attachments/assets/fbd401b5-ec6b-4bdb-9ed7-7f54306a108f" />
<img width="1054" height="534" alt="Image" src="https://github.com/user-attachments/assets/54409d21-d6e9-4e6b-8def-551079a91125" />

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #34890
  • #34555
  • #34003

Powered by Codex Action

Mr-D-Joe · 1 month ago

I reviewed the suggested issues.

This report appears related to the same broader class of unbounded or very large task-history failures, but I do not believe it is a direct duplicate of #34890, #34555, or #34003.

The distinct failure here is the persistent recovery and lifecycle state after the crash:

  • one long-running task remains incorrectly marked as running after restart;
  • reopening it immediately returns to the crash screen;
  • Retry does not clear or reconcile the running state;
  • the task cannot be terminated, interrupted, or recovered through the UI;
  • UI, execution, completion, and queued-message state appear to diverge.

#34890 focuses on a renderer OOM loop with many concurrent threads, leaked renderer processes, and refetch storms.

#34555 focuses on a non-crashing renderer freeze caused by large @-referenced chat payloads.

#34003 focuses on multi-gigabyte file-change history and Invalid string length.

A large task history may still be the trigger in this report, but the unrecoverable persisted running state and missing termination/reconciliation path appear to be a separate lifecycle-recovery defect.

I will therefore leave this issue open unless maintainers identify a canonical issue covering this specific recovery-state failure.

onmokoworks · 1 month ago

macOS reproduction with concrete evidence (goal stuck active after force-quit, then app-server pegs CPU on reopen)

Codex Desktop: 26.721.41059 (Build 5848), session CLI 0.144.2
macOS: 15.7.2 (24G325), Apple Silicon

A long-running goal thread was killed mid-turn (force-quit while a tool call/reasoning step was in flight). The session rollout log (~/.codex/archived_sessions/rollout-...jsonl) ends abruptly on a reasoning response_item with no following task_complete/turn_complete event, confirming the process died mid-turn.

~/.codex/goals_1.sqlite (thread_goals table) shows that goal's status remained active, with updated_at_ms frozen at the exact same timestamp as the last log line. 11 days later it was still active, and thread_goal_continuation_deferrals had no row for it — so there's no persisted "wait for user before continuing" flag.

Separately, an unrelated app-server process for the same CODEX_HOME survived a full quit-and-relaunch of ChatGPT.app (old process kept running with 34+ min accumulated CPU while a new one was spawned). Looks like the same root cause as #32793.

Net effect: opening a thread whose goal is stuck at active causes sustained ~100% CPU on the codex app-server process (confirmed via ps/top: ~1s of CPU time accumulating per 1s of wall time, continuously) with no visible task running — matching the "keeps it marked as running" behavior described here.

Suggested fix direction: on app-server startup, goals left active with no continuation turn actually in flight should be reconciled to paused (or require explicit user confirmation) rather than being eligible for silent auto-continuation when the thread is opened.