[Windows][26.908.4834.0] Large task load crashes renderer, leaves stale turn and blocks queued follow-up

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

26.908.4834.0 (embedded Chromium 152.0.7977.83)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

A single long-running local Codex task became hazardous to load in the Windows desktop app. Selecting, resuming, or sending a follow-up to that task repeatedly terminated and recreated the renderer while the main desktop process and app-server survived.

The rollout remained structurally valid and the conversation was not lost. Sanitized measurements before the recovery turn:

• rollout size: 763,823,778 bytes (about 764 MB)
• valid JSONL records: 198,909
• invalid JSON records: 0
• largest individual record: about 14.4 MB
• about 514 MB was duplicated function/custom-tool output represented in both output and completion records
• projected history: 18,256 items and about 197 million characters
• projected image-generation items: about 98.6 MB

The final persisted turn had no completion event and remained indexed as inProgress after the renderer failure. A follow-up message could be inserted into the local queue, but the unloaded task would not process it. Attempts to wake or resume the task caused another renderer restart or remained indefinitely stuck while loading the history.

The task recovered only after the stale final turn's indexed status was reconciled to interrupted using its already-verified rollout endpoint. After the next app restart, the existing queued follow-up ran as a new turn, wrote a small handoff file, completed normally, and consumed the queue entry. The oversized original task was then archived to prevent further active loading.

No conversation data, local paths, task IDs, feedback IDs, credentials, project names, prompts, or raw logs are attached publicly. A private in-app feedback report was submitted separately.

What steps can reproduce the bug?

This is workload-sensitive rather than a small deterministic fixture:

1. Use one local Codex task for a long period with many tool calls and some image-generation activity.
2. Allow its valid rollout to grow into the high hundreds of megabytes, including repeated multi-megabyte tool-output/completion records.
3. Interrupt the active turn by a renderer crash or desktop restart before a completion event is persisted.
4. Relaunch Codex Desktop and select or resume that task.
5. The renderer may terminate/restart while the main process and app-server remain alive.
6. Queue a follow-up while the task is unavailable. The queue row persists, but the task remains unloaded or falsely active and the message does not run.
7. Reconcile the stale turn to interrupted without changing the rollout, then restart the app. In this incident, the queued follow-up immediately became runnable and completed.

What is the expected behavior?

• Opening a large task should use a metadata-first, paginated, or bounded-history path instead of hydrating the full rollout into renderer state.
• A renderer restart should reconcile any abandoned inProgress turn to interrupted automatically when there is no live owner.
• Queued messages should not remain permanently blocked behind a stale turn.
• Oversized or duplicated tool-output records should be bounded, deduplicated, summarized, or stored by reference.
• If a task exceeds safe client limits, Codex should offer a recoverable handoff/archive workflow instead of repeatedly crashing while loading it.
• Recovery must preserve the original rollout and should not require unsupported manual SQLite changes.

Additional information

The app had two confirmed renderer Crashpad events on the incident day. A replacement renderer reached roughly 2.7 GB working set soon after recovery began. Windows did not record a resource-exhaustion event or display-driver reset near those crashes, and the machine still had roughly 10 GB RAM available. Historical Windows telemetry had also recorded memory-leak warnings for the desktop and app-server processes.

The rollout grew to about 765 MB after the successful bounded recovery turn. Archiving removed it from active loading and stopped the immediate recurrence; archiving did not reduce its on-disk size.

Possibly related, but each covers only part of this chain:

• #45162 — large local thread crash with intact rollout and incomplete projected history
• #45247 — renderer-only native termination on the same Windows app version
• #45209 — queued follow-up lifecycle failure
• #26352 — oversized thread/resume payloads and metadata-first loading
• #37803 — unbounded duplicated event payloads making a task inaccessible

The distinguishing evidence here is the combination of a valid high-volume rollout, renderer failure during load, an orphaned inProgress turn, a durable but blocked queued message, and successful queue recovery immediately after stale-turn reconciliation.

No source files, tests, or entry points are named. Start by comparing the behavior with related issues #45162, #45247, #45209, #26352, and #37803, then investigate large-rollout loading, stale inProgress turns, and queued follow-ups. Done means recovery no longer requires manual SQLite changes, large tasks avoid renderer failure, and queued messages become runnable after an abandoned turn.