Codex Desktop meta-bug: unbounded session/turn state causes freezes, context bloat, and lost active-turn control

Open 💬 15 comments Opened Jun 2, 2026 by FromAriel

💡 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.527.60818

What subscription do you have?

pro

What platform is your computer?

Microsoft Windows NT 10.0.19045.0

What issue are you seeing?

Codex Desktop meta-bug: unbounded session/turn state causes freezes, context bloat, and lost active-turn control

Suggested labels

bug, app, session, context, tool-calls, performance, app-server

Summary

Several open Codex issues appear to be different symptoms of the same larger reliability problem:

Codex Desktop allows local session/turn state to become unbounded, then places that state on hot UI, resume, context assembly, IPC, and active-turn ownership paths. Once a thread is long-running, tool-heavy, image-heavy, repeatedly compacted, or has experienced renderer/restart/interrupt recovery, the app can freeze, become extremely slow, overfill context, lose trace/progress visibility, fail Stop/cancel, or continue backend work while the UI appears stuck in Thinking.

I do not think every linked issue is the same single code bug. The clearer framing is one parent/meta bug with several fix surfaces:

unbounded persisted rollout/session records;
full-history hydration into app-server/client/renderer state;
context replay/compaction retaining large tool or image payloads;
renderer/app-server turn ownership and trace-stream rehydration losing authority;
insufficient diagnostics, because very different waits all collapse into Thinking, Working, or Reconnecting.

Evidence from related open reports

1. Large local rollout/history hydration makes Desktop slow, frozen, or unrecoverable

#18693 reports a verified A/B profile test where a copied profile is smooth until only a few giant local histories are restored. Largest anonymized rollouts were about 455 MiB, 507 MiB, 561 MiB, 584 MiB, and 1867 MiB; operations such as resume/read/unsubscribe could take tens of seconds, with worst cases around 82s.
#20269 reports a long-running Windows Desktop task producing a 718.6 MB rollout JSONL with 3,305 lines. After force quit, every launch auto-resumed the oversized session and froze. Renderer CPU was around 140% of one core and working-set memory grew by about 1.177 GB in 10s.
#22991 reports multiple long-running session files around 500 MB or larger. The strongest freeze occurred not merely when opening a large conversation, but when sending a new prompt in an already-open large thread.
#11984 is the long-running umbrella report for Desktop UI lag during long sessions. Later comments tie the problem to full history hydration, renderer CPU/RSS, and large IPC/app-server payloads rather than only DOM rendering.
#21299 reports Windows long-thread message submit lag: sending a new message in a long thread makes the app unresponsive for about 5s, and pruning old local JSONL session files is reported as a workaround.

2. Hard size limits and inline payloads expose the same design failure

#22004 reports a reproducible Electron main-process crash, RangeError: Invalid string length, when loading sessions whose rollout JSONL exceeds V8's max string length. Reported sizes include 506.8 MB, 786.7 MB, 963.5 MB, 1050 MB, and 1601 MB. Related comments report an 825 MB rollout producing a dropped 405 MB IPC payload, and a macOS 1.37 GB rollout where app-server grew to 6-8 GB RSS.
#24676 shows that the problem can occur below the hard 512 MB crash threshold. A 182.8 MB image-heavy rollout had 41,361 lines, a max JSONL line of 6,850,815 chars, and many inline image_url / payload.images records. A newer repro was only 102.44 MB, but almost the whole file was data:image payloads; a compacted record alone was 24.207 MB with 16 image references.
#22091 reports Desktop context growth from retained tool outputs: a fresh session reached 137,293 / 258,400 tokens after a small number of visible interactions, and an earlier diagnostic reached 234,757 / 258,400, then re-inflated after compaction. Several retained tool outputs were around 37K-40K characters each.

3. Context compaction/replay can amplify the same state bloat

#25009 reports Desktop becoming slow or stuck after context_compacted events and approval transcript injection. The report found repeated approval assessment / TRANSCRIPT DELTA blocks containing prior tool calls, tool outputs, retry reasons, and planned actions.
#24095 tracks Windows memory spikes and freezes after repeated context compactions in a single long-running session, distinguishing this from one-time renderer regressions or image-only rollouts.
#19842 reports Codex CLI running out of context instead of compacting/resuming a long tool-heavy thread. One tool output had an original token count of 815,104; the final token-count event reached 258,400 / 258,400.
#19585 is nominally about usage depletion, but the useful overlap is the "compaction tax": failed/slow compaction and repeated reconstruction consume additional usage and make long-session failure more expensive.

4. Active turn ownership and renderer/session state can desynchronize

#24287 reports the dangerous control-plane symptom: prompt accepted, UI stuck in Thinking, Stop fails or is misleading, progress traces disappear, and backend usage can continue decreasing while no activity is visible. It also reports multi-window rehydration making already-visible traces disappear and state disagreements between the goal bar, prompt box, and chat/trace area.
#24434 reports a post-tool continuation stall: pwd and rg --files returned successfully almost instantly, then no assistant message, no new tool call, and no task completion occurred for about 6m59s until manual interrupt.
#24263 gives concrete renderer rehydration evidence. After a renderer reload, logs showed placeholder latest-turn rebinding, completed turns marked markedStreaming=true, Received turn/started for unknown conversation, and 5,466 Item not found in turn state errors in one Desktop log.
#23644 reports composer submit timing out after stale conversation state accumulated over several days. Local app-state snapshots included pending_request_count=20, thread_count_active=15, thread_count_streaming_owner=6, thread_count_streaming_without_active_runtime=13, item_count_total_loaded=22550, and about 201 MB of estimated delta bytes. Restart cleared the issue.
#23035 reports an orphan task_started without task_complete poisoning reopen/resume. The rollout parsed cleanly, but balancing the orphan turn with a synthetic completion made the lifecycle valid again. This suggests interrupted/failed turns need durable terminal state or tolerant resume logic.
#21360 reports multiple turn lifecycle stall modes: task_started without task_complete, tool outputs returned without assistant continuation, and long non-image sessions with multiple compactions and unfinished turns.

5. Transport/first-output stalls are adjacent and currently indistinguishable in the UI

Some reports may not share the same local-history root cause, but they matter because the UI collapses them into the same stuck state and recovery paths can interact with renderer/session state:

#24260 reports a gpt-5.5 xhigh turn accepted immediately, then 30m38s before the first persisted reasoning item. Later comments include responses_http idle spans of hundreds of seconds and a packet-capture case where a reused connection was reset but recovery waited for the 300s stream idle timeout.
#24414 reports the VS Code extension staying on Thinking for minutes even for simple prompts.
#24419 reports CLI Working hangs and reconnect retries; interrupting and resubmitting the same prompt can run normally.

These may require separate transport/request watchdog fixes, but the Desktop issue should still distinguish them from renderer detachment, post-tool continuation stalls, and full-history hydration.

Suspected root cause family

The common design problem seems to be that "thread state" is doing too many jobs at once:

durable audit log;
UI transcript;
context replay source;
app-server resume payload;
renderer live state;
trace/progress stream state;
tool output/image artifact store;
recovery source after restart or renderer reload.

When those roles are all served by unbounded JSONL and large in-memory turn arrays, one oversized or inconsistent thread can poison many surfaces.

Requested fixes / invariants

Bound persisted session records

Cap persisted function_call_output, custom tool output, event_msg payloads, and InputText/image fields before they enter rollout JSONL.
Do not persist raw data:image / base64 image payloads in normal rollout records or compacted.payload.replacement_history; use file/blob references, hashes, or placeholders.
Avoid duplicating the same image/tool payload across both response_item and event_msg.
Add rollout size warnings and automatic safe repair/export paths.

Make thread loading lazy and paged

thread/read, thread/resume, thread/turns/list, stream-state snapshots, and sidebar state should have hard byte/count caps.
Opening a thread should return metadata and a recent bounded tail, for example the most recent 100-200 messages or a small byte cap.
Older turns, heavy tool outputs, and images should load only on scroll/expand.
Transcript rendering should be virtualized, but virtualization alone is insufficient if full history is still hydrated into renderer/app-server state.

Separate context assembly from durable transcript history

Context compaction should summarize or reference old heavy content instead of replaying raw tool outputs/images.
Approval transcript or retry transcript injection should be bounded and deduplicated.
Context/token accounting should expose whether growth came from visible user text, hidden tool output, compaction replacement history, approval transcript injection, or old transcript replay.

Make active-turn ownership durable and recoverable

Persist a turn record and its originating thread before streaming begins.
Persist accepted user prompts before upstream/network submission.
On renderer reload/restart, reattach by durable turn id and event cursor, not just in-memory renderer state.
Stop/cancel should resolve to an explicit state: cancelled, still running remotely, already completed, failed to cancel, or unknown/detached.
If backend active turns exist without renderer ownership, show a recovery banner and reattach option.

Make resume/reconciliation authoritative

A terminal backend turn must not rehydrate as markedStreaming=true.
If a renderer receives item deltas for an unknown conversation, it should buffer briefly and force a thread/turn re-read instead of dropping state and spamming Item not found in turn state.
On resume, reconcile the full item id set for the active/recent turn before applying live deltas.
Orphan task_started turns should be repaired as interrupted/failed during resume rather than crashing LocalConversationPage.

Improve diagnostics

Add phase-specific timing/log events for: request accepted, upstream request sent, response headers received, first byte, first Responses event, first assistant/reasoning/tool item, tool result returned, post-tool continuation requested, context compaction started/completed, renderer attached/detached, and Stop/cancel result.
Keep performance traces locally if upload fails (#24262).
Preserve enough local diagnostics to tell whether a stuck turn is model/backend stall, transport retry, context compaction, app-server hydration, renderer detachment, or post-tool continuation loss.

Related issues

Large history / full hydration:

#11984
#18693
#20269
#21299
#22991

Hard size limits / image or tool payloads:

#22004
#24676
#22091

Context compaction / context replay / usage amplification:

#19842
#19585
#24095
#25009

Turn lifecycle / UI ownership / trace and Stop desync:

#21360
#23035
#23644
#24263
#24287
#24434

Adjacent transport / first-output stall reports that should be distinguished in diagnostics:

#24260
#24414
#24419

Potentially adjacent Desktop lifecycle reports:

#22655
#25094
#21076

Why this should be tracked as a meta issue

Individual reports often look like separate bugs because the immediate symptom differs: slow thread switching, V8 string crash, image-heavy freeze, compaction memory spike, stuck Thinking, invisible active turn, failed Stop, composer timeout, missing tool traces, or CLI/extension first-output stalls.

But the recurring evidence points to one architectural boundary that needs a coordinated fix: Codex should treat durable history, model context, renderer transcript, live turn stream, and recovery state as separate bounded contracts. Until those contracts are bounded and authoritative, fixes to only one surface, such as rendering virtualization or a single timeout tweak, are likely to leave other variants open.

What steps can reproduce the bug?

User-visible failure modes

Desktop becomes slow or unresponsive when opening a long thread, switching threads, sending a new prompt in an old thread, or after repeated context compactions.
The app can become unrecoverable on launch if the most recent session auto-resumes an oversized rollout.
A short follow-up in an old session can freeze the UI even though a fresh session still works.
Tool outputs can return successfully, but the assistant continuation never resumes.
A prompt can be accepted and backend work can continue, while the Desktop UI stays stuck in Thinking and no progress traces appear.
Stop/cancel can become unavailable, misleading, or ineffective because the UI has lost the active turn reference.
After restart or renderer reload, prompts/traces/tool calls can be missing, stale, or only partially recovered.
The same root state bloat can also drive fast context growth and usage drain through retained tool output, compaction history, and replayed approval/diagnostic transcripts.

What is the expected behavior?

Expected behavior

Opening or switching to a thread should load metadata plus a bounded recent tail, not the entire transcript/tool/image history.
Sending a short prompt in an old thread should not synchronously parse, render, serialize, or replay hundreds of MB of session data.
Context compaction should reduce active prompt pressure and should not retain raw large tool outputs, image data, or repeated transcript-injection blocks.
Rollout JSONL should not store raw image bytes or unbounded tool output inline when references, caps, summaries, or external artifacts would work.
If one thread is too large or malformed, Desktop should fail that thread safely while leaving the rest of the app usable.
If a prompt is accepted, the originating thread should durably show the user prompt, trace/progress stream, and Stop/cancel state.
If the renderer loses ownership of an active backend turn, it should show an explicit recovery/reattach state rather than generic Thinking.
Terminal backend states should be authoritative: completed, failed, interrupted, or cancelled turns should not rehydrate as streaming.
Tool-returned, waiting-for-first-output, reconnecting, context-compacting, renderer-detached, and post-tool-continuation-stalled states should be distinguishable in UI and logs.

Additional information

_No response_

View original on GitHub ↗

15 Comments

github-actions[bot] contributor · 2 months ago

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

#24510
#25390
#24676
#24336
#24434

Powered by Codex Action

lzy18001500226 · 2 months ago

I can add another Windows Desktop datapoint that seems to fit this meta-bug.

In a long-lived Windows-native Codex Desktop workspace with many visible project threads, large transcripts, frequent cross-thread dispatches, context compaction events, interrupted turns, and recurring automations, individual threads can remain listable/readable while new turns fail to start or settings updates fail with errors such as:

failed to update thread settings: internal error; agent loop died unexpectedly
failed to start turn: internal error; agent loop died unexpectedly
Error submitting message

The important distinction is that fresh/empty threads can still accept simple messages, and restarting Codex Desktop / Codex++ often temporarily restores the same affected visible thread. So this does not look like a global account/network failure or a project-specific runtime failure. It looks more like stale or inconsistent thread/conversation/app-server state after long-lived multi-thread usage.

Local scale indicators from the affected workspace:

about 144 total thread records
about 120 project thread records
largest orchestration transcript around 532 MB
operations/patrol transcript around 173 MB
diagnostic history around 701 MB
repeated context compaction / interrupted / markedStreaming=true style evidence in local logs
Related surface also overlaps with #23971, but our trigger is not only subagent close; it is broader Windows Desktop long-lived visible-thread dispatch/start-turn degradation.

A useful product-level fix would be to expose a clearer per-thread state, for example: readable/listable but not routable, approval pending, compaction pending, stale runtime, or agent-loop failed. Right now those states can collapse into the same practical outcome: the thread looks present but cannot be safely used for automation or dispatch.

ooiuuii · 2 months ago

Adding a Windows Desktop data point that seems to fit this meta-bug, especially the distinction between local runtime stalls and degraded thread/session state.

In my case, two problems initially looked like the same "Codex is stuck" symptom, but they turned out to be different layers:

One project under a OneDrive-backed Documents/New project path was genuinely I/O-bound. A pnpm install had produced a partially built node_modules with about 90,910 files / 2.8 GB, and the project also had .worktrees around 250,160 files / 6.23 GB plus .git around 2.44 GB. Moving/cloning the active repo to a non-synced F:\openclaw\repos\... path made the dependency install finish in about 17s and Vite become ready in about 2s.

A separate old Codex Desktop thread was not explained by local I/O. At diagnosis time there was no active shell, pnpm, gh, or similar subprocess, local CPU/RAM pressure was low, and the thread was already near the effective context window at about 232k / 258k tokens. It had accumulated large prior diagnostic/tool output (doctor --fix, rg, gateway checks, etc.). That thread remained unsafe to continue even after the workspace I/O issue was fixed, so I abandoned it and continued from a short-context thread.

The useful distinction for this issue is: Desktop should not make these both look like generic Thinking/stuck states. It would help if the app could expose whether the current stall is:

a live local subprocess;
a post-tool continuation stall after subprocess completion;
app-server/thread hydration or renderer reattachment;
context compaction / near-window pressure;
model/Responses stream waiting for first output;
local workspace I/O risk from OneDrive/cloud-sync and huge file counts.

The product-level recovery also needs to be different. Moving the repo out of OneDrive fixes the I/O stall, but it does not rescue a degraded long-context thread. For that second case, Codex needs a safe fork/handoff/degraded-session path rather than encouraging the user to keep prompting the old thread.

I filed the narrower diagnostic-boundary issue as #28345, so this comment can stay focused on how the datapoint fits the broader session/context meta-bug.

nasadunadu · 1 month ago

Adding a macOS data point with a concrete IPC hard-limit failure from an oversized local rollout.

Environment

macOS (Apple Silicon)
Codex Desktop: 26.707.41301 (build 5103)
Renderer: 150.0.7871.115
Bundled CLI / app-server: 0.144.0-alpha.4

Local state before mitigation

active Codex data: approximately 5.4 GB
active sessions: approximately 1.3 GB
archived sessions: approximately 2.6 GB
largest rollout files: approximately 902 MB, 574 MB, and 350 MB

The thread list itself remained fast (about 276 ms). Reading recent/light threads took about 165-393 ms. The 574 MB and 902 MB histories took about 1.26 s and 1.95 s for a bounded recent read.

However, reading the approximately 350 MB history failed after about 2.8 seconds with a concrete IPC frame error:

code-mode delegate response exceeds the IPC frame limit: code-mode IPC frame length 81989668 exceeds 67108864 bytes

This occurred even when the caller requested a bounded recent read and set output inclusion off. The returned payload path still attempted to construct approximately 82 MB for a protocol with a 64 MB single-frame limit.

Mitigation result

Moving old oversized rollouts out of the hot scan path reduced the active Codex directory from about 5.4 GB to about 2.0 GB and improved general responsiveness. The histories were preserved in a verified compressed cold backup. This is an effective local workaround, but users should not need to manually manage internal JSONL files to keep Desktop usable.

Requested invariants

hard byte/count limits before app-server or code-mode responses enter IPC
honor bounded reads and output-exclusion options across every response layer
replace inline heavy tool/image payloads with references or explicit expandable placeholders
show rollout-size warnings before a thread approaches renderer/V8/IPC limits
provide a supported archive/export/repair workflow for oversized histories
one oversized thread should fail safely without degrading navigation or other threads

I have omitted local paths, thread IDs, raw conversation content, account data, and credentials.

wherewolf87 · 1 month ago

Adding a Windows Desktop datapoint with a deterministic failure on one oversized, long-lived thread.

Environment

Codex Desktop for Windows: 26.707.3748.0
Windows 11 x64
Subscription: Pro

Local evidence

The affected rollout is 455.67 MiB with 43,086 JSONL records.
Its last persisted turn reached task_complete; the thread remains present and listable.
Recent token events reached the five-hour window's 100% marker while the in-flight turn continued to its terminal event.
The UI then showed a usage-limit message, but submitting a follow-up surfaced only generic internal-error UI.

Reproduction

Open the affected long-lived thread.
Submit a short follow-up such as continue working.
The UI shows Error submitting message and/or a red Error creating task toast.
Reproducing through the Desktop thread API without a model override returns:

failed to start turn: internal error; agent loop died unexpectedly

Reproducing with a lower-cost model override fails before the turn starts with:

failed to update thread settings: internal error; agent loop died unexpectedly

A same-directory fork attempt does not complete successfully.

The original rollout remains parseable and its prior terminal event is intact. No active local subprocess explains the failure.

Expected behavior

A usage or model quota rejection should surface as a precise rate-limit response, not agent loop died unexpectedly.
A completed oversized thread should remain safely routable through bounded/lazy state, or the app should offer a supported compact continuation that does not copy the entire hot history.
Switching to an available lower-cost model should either start successfully or return the actual account/model limit.
A fork should fail with an actionable size/state error rather than aborting generically.

This appears consistent with the meta-bug's unbounded history plus thread-routing failure family, while also exposing a misleading usage-limit-to-internal-error mapping.

uatragada · 1 month ago

Additional Windows evidence from July 11, 2026. This variant presents as repeated full Desktop process exits/relaunches, not only an in-place renderer reload.

Environment

Windows 11 Home, build 26200, x64
Codex Windows Store package: OpenAI.Codex_26.707.3748.0_x64__2p2nqsd0c76g0
Separate installed CLI: codex-cli 0.144.1
Multiple concurrent active threads/turns; in-app browser/sidebar activity was present

Observed process lifecycle

The Desktop logs show several sessions ending abruptly without the normal:

[AppServerConnection] Stopping app-server transport

A new Desktop process was then launched shortly afterward:

PID 34408: last log 2026-07-11T21:05:06.363Z
PID 50052: Launching app 2026-07-11T21:05:10.822Z

PID 50052: last log 2026-07-11T21:44:59.471Z
PID 26268: Launching app 2026-07-11T21:46:34.140Z

PID 26268: last log 2026-07-11T22:14:37.615Z
PID 27812: Launching app 2026-07-11T22:14:41.165Z

The third sequence ended immediately after stale-conversation events and browser-sidebar teardown:

2026-07-11T22:14:37.114Z error Received item/started for unknown conversation conversationId=<redacted>
2026-07-11T22:14:37.386Z error Received item/completed for unknown conversation conversationId=<redacted>
2026-07-11T22:14:37.615Z info IAB_LIFECYCLE renderer removed browser sidebar webview ... tabType=web
<log ends>
2026-07-11T22:14:41.165Z info Launching app ... platform=win32

Error volume before exits

Main-process/Desktop logs for the affected runs contained:

Session PID 34408 (3h45m):
  errors: 138
  warnings: 248

Session PID 50052 (40m):
  errors: 502
  warnings: 93

Session PID 26268 (28m):
  errors: 1,729
  warnings: 91

Session PID 27812 (16m):
  errors: 728
  warnings: 137

Across these sessions, the dominant error categories were:

1,092  Received item/completed for unknown conversation
1,084  Received item/started for unknown conversation
  688  Conversation state not found
  142  ResizeObserver loop completed with undelivered notifications
   41  Received turn/started for unknown conversation
   34  Received turn/completed for unknown conversation

One affected session started emitting Received turn/started for unknown conversation only seconds after startup while other threads were actively streaming. Subsequent events for that conversation continued for the life of the process.

Negative evidence

No matching Windows Application Error / Windows Error Reporting record
No Codex/Electron dump in the package Crashpad paths
No WER report archive entry
Sentry queue was empty
No evidence of an out-of-memory condition:
approximately 17 GB physical memory available
approximately 21 GB committed against a 63 GB commit limit

This makes system memory pressure and a conventional WER-captured native crash unlikely.

Assessment

This appears consistent with the active-turn/renderer state desynchronization family tracked here and in #24263, but this instance escalates into repeated full Desktop process termination/relaunch. The strongest trigger correlation is multiple concurrently streaming threads plus browser/sidebar lifecycle activity. Exact reproduction is still timing-sensitive.

Useful fixes/diagnostics would include:

buffering/reconciling events for an unknown conversation instead of continuously applying and logging them;
recording an explicit main/renderer exit reason before relaunch;
preserving Crashpad/Sentry evidence for these exits;
making browser-sidebar teardown safe while active or detached turns still exist.

hug1997 · 1 month ago

Additional macOS reproduction from Codex Desktop release 26.707.72221 / bundled CLI 0.144.2:

Fresh image thread stalled before first output

A brand-new local thread was created with two ordinary PNG attachments (~466 KB and ~1.4 MB).
Actual thread ID: 019f5fe0-c206-7100-89a8-05c9dc96e3e9.
Desktop accepted turn/start in ~29 ms.
In the same second, the Desktop log emitted:

Received turn/started for unknown conversation
with conversation ID 019f5fe0-c309-7851-a255-c58d8a12d928, which did not match the actual thread ID.

After the accepted turn/start, there was no persisted reasoning item, assistant message, tool call, completion event, or explicit error.
The UI remained active / inProgress until the turn was manually interrupted roughly 3 minutes later.
Fully quitting and restarting Codex cleared the stale behavior.

The unknown conversation event is correlated with the stall but is not proven to be the root cause. It may indicate a thread/turn routing or renderer reattachment race. The important user-facing issue is that the app exposed only a generic active/thinking state and no recoverable phase-specific error.

After restart, the image pipeline completed again but remained very slow: 130.7 seconds cold and 45.4 seconds warm for a trivial one-line response. That controlled performance reproduction is tracked in #33018.

No private image content or raw logs are included in this comment.

qihangzhang-272 · 1 month ago

Adding a reproducible Windows Desktop datapoint with a same-version CLI control test.

Environment:

Codex Desktop (Microsoft Store): 26.707.9981.0
bundled/local CLI: codex-cli 0.144.2
Windows x64
Pro subscription
affected rollout uses history_mode=legacy

Observed failure:

The affected thread remained readable through the paged thread-read path and its most recent turn was completed.
The original working directory still existed.
The rollout was 108,119,172 bytes and 4,190 JSONL lines before the control test.
SQLite reported 107,493,536 cumulative tokens for the thread; the last completed turn used about 57.6k tokens against a 258.4k context window, and the weekly rate limit was only about 11% used.
Starting a new turn through the Desktop/background follow-up path failed twice with:

failed to start turn: internal error; agent loop died unexpectedly

On each Desktop failure, the new prompt was not appended to the rollout JSONL. The composer text remained present in local draft state.
Retrying after a successful CLI resume still failed in Desktop, so the CLI control did not repair the Desktop path.

Same-version control:

Exit any temporary resume process.
From the thread's real working directory, run:

codex resume <redacted-thread-id>

Send a no-tool diagnostic prompt.
The same CLI version (0.144.2) successfully loaded the 108 MB history and returned the requested short response.
Exit the TUI cleanly.
Retry the same short prompt through Desktop/background follow-up: it again fails with agent loop died unexpectedly.

This narrows the failure to the Desktop/background agent-loop lifecycle or thread-loading/ownership path rather than the model, account quota, working directory, rollout parseability, or core direct-resume capability.

Additional signals:

One earlier turn in the rollout had task_started without a matching task_complete, although later turns completed successfully, so stale lifecycle state may be a contributing factor.
At the time of one failed Desktop attempt, structured logs also contained failed to refresh available models: timeout waiting for child process to exit after the models HTTP request itself returned 200. I cannot prove this is causal.
The user observed several threads becoming unable to submit messages around the same time. Local app state contained multiple non-empty composer drafts, but only this thread was tested end-to-end.

Expected behavior:

Desktop should resume/start the turn as the direct CLI path does, or fail with a recoverable per-thread error.
Accepted composer text should be durably persisted before agent-loop startup so a worker failure cannot silently drop the attempted turn.

Privacy:

Thread ID, username, workspace path, prompt contents, and credentials are intentionally redacted.
The raw rollout cannot be attached because it contains private project history.

Related exact error family: #23971. Related long-history/direct-resume behavior: #25215 and #25430. A recent minimal report with the same message was #33206.

FromAriel · 1 month ago

Additional reproducible Windows Desktop datapoint from a newer build, using a bounded PresentMon/process-counter harness.

Environment

Codex Desktop (Microsoft Store): 26.715.3651.0
CLI: codex-cli 0.145.0
Windows 11 Pro x64, build 26200
AMD Ryzen 9 5900X, 12 cores / 24 logical processors
63.9 GiB RAM

Privacy-safe profile metadata

No rollout contents were read. No thread identifiers, titles, prompts, usernames, machine names, or paths are included in this report.

711 rollout JSONL files
29,360,407,532 total bytes (about 27.3 GiB)
63 rollouts at least 100 MiB
11 rollouts at least 500 MiB
4 rollouts at least 1 GiB
Largest rollout: 1,320,589,517 bytes

Reproduction

Close only the Microsoft Store Codex Desktop process tree.
Start PresentMon, one-second Windows system counters, and per-PID process sampling.
Launch Codex through its AppUserModelId with the existing profile.
Wait until a visible Codex window exists and its package-process set remains stable with aggregate Codex CPU at or below 12% for eight seconds.
Continue collecting for 60 seconds after that readiness gate, without user interaction.

The test is bounded by a 150-second hard timeout and stops only its own collectors. Codex is intentionally left running.

Confirmation run

Readiness gate: 17.91 seconds
Total captured duration: 78.02 seconds
Maximum aggregate Codex CPU: 16.65% of total machine capacity
Maximum aggregate Codex working set: 2,082 MB
Maximum single renderer working set: 494.91 MB
Maximum app-server working set: 219.63 MB
Maximum Desktop main-process working set: about 1,213 MB

PresentMon recorded 2,575 Codex frames:

1,589 over 16.67 ms
265 over 50 ms
180 over 100 ms
2 over 500 ms
1 over 1,000 ms

Worst frame:

Frame time: 1,083.52 ms
CPU busy: 1,083.39 ms
GPU latency: 1,056.56 ms

A separate frame spent 778.62 ms in CPU wait. Maximum C: write latency was 677.38 ms, and the Windows processor queue peaked at 21. DPC and interrupt percentages remained low.

Between topology snapshots at 16 and 78 seconds, Windows Win32_Process.ReadTransferCount increased by:

Desktop main process: about 2,836 MiB
app-server codex process: about 79 MiB

ReadTransferCount combines file, pipe, and device I/O, so this does not by itself prove 2.8 GiB of disk reads. Given the much smaller app-server transfer count and the late Desktop memory growth, one plausible interpretation is a very large IPC/history-hydration payload entering the Electron main process after the app was already visibly ready. That interpretation needs ETW or app-server phase logging to confirm.

Independent preceding run

The immediately preceding 80-second run showed the same broad pattern:

Maximum aggregate working set: 2,174.5 MB
Maximum frame time: 1,204.25 ms
Desktop main-process read-transfer increase from 16 to 76 seconds: about 1,889 MiB

This makes the greater-than-one-second frame stalls and multi-gigabyte post-ready process transfer reproducible across two launches. The exact disk-latency peaks varied substantially between runs, so disk latency should not yet be treated as the primary cause.

Limitations

No mouse or keyboard interaction occurred, so PresentMon input-to-photon fields are empty.
The trace establishes correlation with a very large local history profile; it is not yet a clean-profile A/B test.
Raw rollout files and the state database are private and are not attached.
Raw system-counter CSVs contain the local machine name and should be sanitized before sharing.

The next discriminating test would compare the same action in a fresh/small thread and a known large thread while recording short ETW file/pipe I/O and phase-specific app logs.

I can provide a santized Data packet from the presentmon run on request.

kingsleyonoh · 29 days ago

Adding a current Windows Desktop reproduction from 26.721.4979.0. This is not Windows-only. #35279 and #22283 provide macOS reproductions of the same history-processing family, but this Windows case shows severe profile-wide degradation from parent/subagent fan-out even though no individual rollout is near the 500 MB+ hard-failure range.

Environment

Windows 11 x64, build 26200
Microsoft Store package: OpenAI.Codex_26.721.4979.0_x64__2p2nqsd0c76g0
Intel Core i7-13700H, 20 logical processors
32 GB RAM

Privacy-safe session metadata

No rollout contents, project names, paths, prompts, thread IDs, client information, or credentials are included.

Refreshed profile snapshot:

234 rollout JSONL files
2,594.5 MiB total
60 rollouts over 10 MiB
14 rollouts over 50 MiB
largest/active parent rollout: 198.9 MiB

A grouped metadata-only scan immediately before that refresh showed that one long-running parent task and its subagents accounted for:

177 rollout files
2,431.6 MiB
approximately 94% of the entire active session store
multiple individual subagent rollouts between approximately 95 and 107 MiB

The parent task remained active and continued growing while unrelated Desktop tasks were also active. During the same diagnostic window, the overall session store grew from approximately 2.01 GiB to 2.59 GiB as the parent/subagent workload continued.

User-visible impact

Codex Desktop becomes intermittently unresponsive while typing, switching tasks, or receiving background task/subagent updates.
The degradation affects unrelated Codex tasks, not only the oversized parent task.
When the freeze is severe, other Chromium/UI surfaces on the machine also become difficult to use.
Windows recorded a real Application Hang event (Event ID 1002) for the packaged ChatGPT.exe / Codex app at 2026-07-28 15:10:25.

Resource and negative-control evidence

A clean process-counter sample during the degraded state did not show ordinary machine saturation:

approximately 8.6 GiB physical memory remained available
total disk queue was 0 to 0.01
aggregate CPU was nearly idle during the sample
Codex/ChatGPT processes used approximately 2.2 GiB working set
the renderer and main process were each around 0.8 GiB working set

The freeze is intermittent, so a process can report Responding=True between stalls. On this 20-logical-processor system, one blocked or saturated renderer thread can also remain visually severe while appearing small in whole-machine CPU percentages.

Additional controls:

the separate Pi/Ubuntu runtime was stopped; the problem continued
repository git status checks completed in approximately 116-212 ms
disk queue remained effectively zero
a prior Chromium/cache reset did not provide a durable fix
the installed Microsoft Store build was current at the time of testing

This makes general CPU, RAM, disk, Git, repository scanning, or the separate harness insufficient explanations for the observed Codex freeze.

Cross-platform comparison

#35279 confirms that macOS can freeze while rerendering an 813 MB JSONL on window-focus changes. #22283 provides a macOS A/B reproduction where restoring one large historical message made unrelated live UI interactions choppy again. Therefore the core unbounded-history/hydration problem is cross-platform.

The Windows-specific question is whether the packaged Desktop renderer, main-process IPC/state reconstruction, or concurrent active-task handling makes the same architectural problem become system-disruptive at a smaller per-rollout size. This reproduction cannot prove a lower Windows threshold, but it does show severe failure with a 198.9 MiB largest rollout when the related parent/subagent tree totals approximately 2.43 GiB.

Requested safeguards

Treat a parent task plus its subagent rollouts as one bounded history tree for loading and resource accounting.
Do not hydrate completed subagent histories into unrelated hot UI, sidebar, resume, or renderer state.
Apply hard byte/count limits before history crosses app-server/IPC/renderer boundaries.
Load a bounded recent tail and fetch older turns/tool output only on demand.
Parse/index large histories off the renderer's interaction path.
Show per-thread and per-task-tree size warnings before responsiveness collapses.
Provide a supported cold-archive/export/handoff flow so users do not have to manipulate internal JSONL files.
One oversized active task tree must not degrade input, navigation, or unrelated tasks across the whole Desktop app.

The practical consequence is serious: a long-running software build can continue producing correct backend work while the official Desktop UI becomes too unreliable to supervise or stop confidently. That turns a performance defect into a trust and control problem for agentic development.

FromAriel · 29 days ago

@etraut-openai Could we please get maintainer attention on this issue?

It has now been open for more than a month without meaningful action, and the Codex desktop app has degraded to the point that it is no longer reliably usable for heavy workloads.

This is not a minor performance inconvenience. When Codex becomes heavily bogged down, the impact can spread beyond the application itself: other Chromium-based applications slow down, input responsiveness deteriorates, the mouse begins stuttering, and the entire computer can become effectively unusable while Codex is running.

This is a severe usability, stability, and resource-management issue, and it needs to be treated as a high-priority engineering problem.

The users most affected are precisely the users putting the app through its intended heavy-use workflows: long-running sessions, many threads, extensive tool use, large histories, and sustained agent activity. Many are already moving back to the CLI because the desktop app cannot remain stable under those conditions.

I understand that my roughly 1,500 threads may represent an unusually heavy workload. However, reports from users with far fewer threads show that this is not limited to one extreme case. Even where a user’s workload exceeds the app’s current practical limits, the application should handle that condition responsibly. It should archive or lazily load old state, cap or rotate logs, reclaim memory, warn the user, offer cleanup tools, or otherwise degrade gracefully.

What it must not do is silently accumulate unbounded state until the application—and in some cases the entire desktop environment—becomes unusable.

At this point, the absence of visible triage, ownership, or a mitigation plan is deeply concerning. This behavior is unacceptable in a production application intended for serious development work, and it is genuinely disappointing given the engineering quality I have otherwise come to expect from OpenAI.

Could a maintainer please:

Confirm that this issue has been triaged.
Assign an owner or relevant team.
Clarify whether the primary causes are known.
Provide any immediate mitigation steps for affected users.
Indicate whether architectural fixes for session hydration, history growth, renderer memory, and SQLite/WAL churn are planned.

Even a candid status update would be substantially better than continued silence. Heavy users need to know whether this is being actively addressed.

For the record my ballooning conversartions.json and related files currently total 67gb!

I sadly need the codex app vs the CLI for one of my projects and I can't afford to switch to CLI. I just hope this project completes before the system becomes unstable completely.

kingsleyonoh · 29 days ago

Follow-up to my Windows reproduction above:

The local session cleanup completed, but it did not remove the typing, cursor, or system-wide composition lag. I deleted 548 non-Brain rollout files totaling about 4.07 GiB, reduced the remaining rollout store to about 262 MiB, removed the old 466.15 MiB Codex log database, and restarted Codex. The lag remained while disk queue, paging, DPC time, interrupt time, and available RAM were healthy.

A second investigation found sustained DWM load, an active Parsec virtual display driver, and a fresh ChatGPT.exe Application Hang 1002. After removing Parsec, its virtual display driver, and its virtual USB driver, then rebooting, DWM fell from 136% of one CPU core on average to about 4.6% after startup settled. Codex became substantially more responsive.

The detailed privacy-safe reproduction and measurement is posted in #33258. This means the original machine had at least two overlapping failure paths:

Unbounded parent/subagent history growth.
A Windows DWM/virtual-display composition failure that remained after the history cleanup.

The Parsec result is not proof that Parsec is the sole cause because the recovery included a reboot. The measured before-and-after result makes virtual-display topology worth recording in future Windows Codex performance reports.

eperez28 · 27 days ago

Additional severe macOS reproduction: 33.7 GB rollout caused ~100 GB process footprint

I hit an extreme instance of this failure in Codex Desktop on macOS.

Environment

macOS 26.3 (25D125)
32 GB physical memory
Bundled Codex CLI: 0.146.0-alpha.9.2
Affected session ID: 019f677b-2268-7892-a849-2f2a7df34ba6
Affected rollout JSONL size: 33,660,241,131 bytes (about 33.7 GB)

Reproduction

Opened a long-running, tool-heavy project thread that had been used as the main build thread since the project began.
Codex Desktop became increasingly slow and unreliable.
Chose Continue in new chat from that thread three times while the new-chat operation remained stuck/spinning.
No usable continued chat appeared.
Activity Monitor showed the Codex app-server process grow from approximately 53.48 GB to approximately 100 GB of memory footprint.
The machine became nearly unusable and required force-quitting ChatGPT/Codex.

System evidence captured before force quit

Physical RAM: 32 GB
Swap in use: approximately 25.7 GB of 26 GB
Codex app-server was consuming sustained CPU
The rollout file itself remained 33.7 GB
The original session and repository were preserved; no transcript/log attachment is included here because it may contain private project data.

Observed failure

The app did not warn about the transcript size, fail the continuation safely, cancel or deduplicate repeated continuation attempts, or isolate the oversized thread from the rest of the app. Instead, memory allocation continued until macOS was under catastrophic RAM/compression/swap pressure.

Expected safeguards

Refuse or safely summarize/stream a continuation from an oversized session.
Enforce hard byte/count limits on initial thread hydration and IPC payloads.
Deduplicate or cancel repeated Continue in new chat operations.
Keep a single pathological thread from exhausting system memory.
Provide a recovery path that preserves the transcript as an archive while creating a bounded handoff.

This appears to be a direct, severe macOS reproduction of the unbounded persisted-session/full-history-hydration problem described in this issue.

Coldain · 25 days ago

Current macOS reproduction: opening one legacy multi-GiB task freezes Desktop while mobile remains usable

I observed a current macOS variant of the large-history hydration failure on:

ChatGPT macOS app 26.727.51351 (build 6119)
bundled codex-cli 0.146.0-alpha.9.2
macOS 27.0 (26A5388g), Apple Silicon, 48 GB RAM

Reproduction and cross-client symptom:

Desktop was running other work, including a Computer Use app test.
I opened an older, long-running task in the Mac app.
The Mac window stopped accepting typing/clicks and the fans accelerated.
I opened the same task on my phone; it remained connected and conversationally usable there while the Mac UI was stuck.

Sanitized live process/open-file observations during the freeze:

Desktop app-server initially reached about 133.8% CPU with 3,912,528 KiB RSS; a later sample was about 64.7% CPU with 3,298,400 KiB RSS.
One Electron renderer remained at roughly 103–104% CPU across a five-second sample. Another renderer fell from an earlier 61% burst to about 4%.
The main app-server held 17 session JSONL files open totaling 12,198,882,630 bytes; the largest open session was 3,442,263,289 bytes (~3.21 GiB).
Aggregate size of those open sessions increased by only 24,247 bytes over five seconds. This was heavy local load without a concurrent multi-megabyte write burst.
System memory was not exhausted (51% reported free).

There were meaningful confounders: Computer Use was active, FileProvider was around 122–137% CPU, and WindowServer around 76–84% during samples while iCloud Documents was also busy. The Computer Use service itself was only around 4–6% CPU. These processes can amplify UI contention, but the task-size/open-file evidence plus the phone/Mac split is consistent with local full-history hydration/rendering being the task-specific trigger. This is an inference, not a claim that every observed CPU cycle came from the old task.

This profile also experienced the session-storage incident reported on #35458, but the important distinction here is that the freeze occurred after the bulk closed-session cleanup and while the open session set was barely growing. That supports treating persisted-history loading/rendering as an independent hot path, not only an unbounded-writer problem.

Requested safeguards align with this meta-issue: byte-capped/paged thread/read and resume, a bounded recent-tail render, pre-open warnings for multi-GiB histories, isolation so one task cannot freeze the whole composer/task switcher, and explicit hydration/progress/cancel/recovery states. Raw session bodies, task IDs, titles, and private logs are intentionally not attached.

38st · 24 days ago

Additional macOS reproduction of terminal backend state diverging from the Desktop UI.

Environment

ChatGPT/Codex Desktop 26.727.51351 (build 6119)
Bundled codex-cli 0.146.0-alpha.9.2
macOS 26.5.2 (25F84), Apple Silicon

Observed

A long, tool-heavy local task completed after roughly two hours.
The task API reported latestTurn.status=completed, no error, and the thread as inactive/notLoaded.
The latest shell card was also terminal (sleep 30, “Succeeded”), and a final assistant answer had already been persisted.
Despite that, reopening the task left the Desktop UI visibly stuck in the running/streaming state. Navigating away and back did not reconcile it.
There was no pending approval and no command still executing.

Expected
A terminal backend turn must be authoritative. When a completed task is opened, Desktop should clear any stale streaming/running indicator and restore normal composer controls. If renderer state disagrees, it should re-read/reconcile the latest turn instead of continuing to present a ghost active run.

The affected task ID and screenshot are intentionally omitted from this public comment but can be shared privately if maintainers need them.