›_ Codex Issues
Codex Issues / #35799

Codex Desktop crashes when ambient suggestions prefetches an inactive image-heavy subagent rollout

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

Summary

Codex Desktop on Windows repeatedly terminated while I was viewing a different task. The affected task was never opened by the user.

Desktop logs show ambient_suggestions / background task loading issuing thread/read for an inactive subagent history. That history had a 646.668 MB rollout containing inline Base64 PNG data. Each of three independent app runs produced the same 36.086 MB Sending server response log record for that inactive task, followed by an abrupt log cutoff 9.571–10.785 seconds later.

This means an inactive image-heavy task can destabilize the whole Desktop app through background prefetch, without user navigation to that task.

Environment

  • Codex Desktop: 26.721.4979.0 x64
  • OS: Windows 11 Home, version 10.0.26200, build 26200
  • Install source: Microsoft Store package OpenAI.Codex

Observed behavior

  1. The user stays in an unrelated active task.
  2. The Codex window is unfocused.
  3. Desktop background activity reads several unrelated tasks.
  4. thread/read is issued for an inactive image-heavy task classified in state_5.sqlite as thread_source='subagent'.
  5. The log records feature=ambient_suggestions immediately around this background read.
  6. Loading the inactive task emits one 36.086 MB Sending server response record containing an inline Base64 PNG.
  7. The app disappears/restarts shortly afterward.

The user did not click, open, or switch to the affected task. In the clearest run, the route remained the unrelated active task throughout the sequence.

Repeated timing

| Run | Large response logged | Final app log entry | Delay |
|---|---:|---:|---:|
| 1 | 00:22:09.893 | 00:22:20.310 | 10.417 s |
| 2 | 00:30:45.795 | 00:30:56.580 | 10.785 s |
| 3 | 00:37:43.396 | 00:37:52.967 | 9.571 s |

All three runs loaded the same inactive subagent history and produced the same 36.086 MB response record before termination.

Local data characteristics

  • Affected rollout size: 646.668 MB
  • Large response log record: 36.086 MB
  • Payload characteristic: inline data:image/png;base64,...
  • Thread classification: subagent
  • Spawn-edge rows for this thread: 0, suggesting an orphaned or migrated subagent record
  • The separately generated PNG file was already absent; the Base64 copy remained embedded in history

The raw rollout cannot be attached because it contains private conversation content and image data. Usernames, paths, task titles, and thread IDs are intentionally omitted here.

Crash diagnostics

  • No matching Windows Error Reporting event was recorded.
  • The Crashpad reports directory was empty.
  • No render-process-gone event appeared in the Desktop log.
  • The exact native termination point therefore remains unconfirmed.
  • The repeated same-payload/same-timing sequence makes the background read of this rollout the high-confidence trigger.

Expected behavior

  • Background suggestions and sidebar prefetch should avoid materializing full image-heavy histories.
  • An oversized or malformed inactive task should fail in isolation and leave the active task usable.
  • History previews should omit, cap, externalize, or lazily load Base64 image payloads.
  • thread/read responses should have size limits and graceful error handling before crossing the Electron renderer/main-process boundary.
  • Orphaned subagent records should not be automatically prefetched as normal sidebar tasks.

Reproduction outline

  1. Create or retain an inactive subagent rollout containing large inline Base64 PNG history.
  2. Keep a different task active in Codex Desktop.
  3. Leave the app idle or unfocused long enough for ambient suggestions/background task loading to run.
  4. Observe thread/read for the inactive subagent without any navigation to it.
  5. Observe the oversized Sending server response record and subsequent app termination.

Related issues

  • #22004 — oversized rollout / V8 string-length crash
  • #24676 — image-heavy rollout hangs on opening
  • #34863 — inline PNG history growth and system-wide memory pressure

The additional failure mode here is automatic background loading: the user never opens the problematic task, yet ambient_suggestions fetches it while another task is active and repeatedly takes down the app.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 1 month ago

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

  • #34863
  • #34890
  • #35458

Powered by Codex Action

millionart · 26 days ago

Additional repro variant on a newer Windows Desktop build (live tool output, not background prefetch)

I observed a closely related silent Desktop termination on a newer build. This variant happened while returning a live view_image tool result from the active turn, rather than while prefetching an inactive historical rollout.

Environment

  • Codex Desktop: 26.727.6591.0 x64
  • Install source: Microsoft Store package OpenAI.Codex
  • OS: Windows 10 Pro 22H2, build 19045.7548
  • Observed: 2026-08-02
  • Several image-heavy threads were active concurrently

Timeline (UTC)

  • 00:01:54.318: an active thread issued functions.exec containing a view_image call.
  • 00:01:54.418: its matching custom_tool_call_output was persisted with an input_image whose image_url was an inline data:image/png;base64,... value.
  • The serialized tool output was approximately 1,031,628 characters.
  • During the final two seconds, app-server logged 187 item/commandExecution/outputDelta events.
  • 00:01:55.466: the app-server log stopped abruptly while output deltas were still being emitted.
  • 00:01:56 local AppModel Runtime time: Windows recorded destruction of the OpenAI.Codex_26.727.6591.0_x64 desktop AppX container.
  • 00:02:57: the app was launched again with the same package version.

The Desktop log had no normal quit/shutdown tail. One thread had also reported failed to start turn: internal error; agent loop died unexpectedly earlier in the same run, but the app remained alive after those errors, so I am treating that as a possible precursor rather than the demonstrated trigger.

Checks that did not find an alternative cause

  • No matching Windows Error Reporting or Application Error event
  • Crashpad reports directories were empty
  • No Resource Exhaustion, Defender, power, or Codex AppX deployment/update event in the crash window
  • No Stop-Process, taskkill, or TerminateProcess command targeting Codex/ChatGPT in the surrounding tool calls
  • The pre- and post-relaunch logs both identify the same Codex package version

Why this may extend this issue

This suggests the failure family may not require a multi-hundred-MB stored rollout or background thread/read. A roughly 1 MB inline image result crossing the live code-mode/app-server/Desktop path, under concurrent activity, was immediately followed by the same silent termination pattern:

  • inline Base64 PNG
  • high-rate IPC/output-delta activity
  • abrupt log cutoff
  • no WER/Crashpad evidence

This is one observed incident and I do not yet have a deterministic minimal reproducer, so the payload/concurrency link is a high-confidence correlation rather than a dump-proven fault location.

The functions.exec + outputDelta signature also overlaps #35341, while the inline image storage/IPC design overlaps #28531. A useful guard would be to cap or externalize input_image data URLs before they are serialized into command-execution deltas or forwarded across the Desktop renderer/main-process boundary.

I can provide additional redacted log/database excerpts if useful; raw rollout data is not attached because it contains private conversation and image content.

millionart · 26 days ago

Follow-up: deterministic 2/2 crash via read_thread on a 970 MB image-heavy rollout

I now have a much stronger reproduction than the single live-image incident in my previous comment. The same oversized historical thread terminated Codex Desktop twice in succession, including once after restart with output retrieval disabled.

Affected local history

  • Rollout size: 1,017,135,795 bytes (970.016 MB)
  • Inline data:image occurrences: 379
  • Codex Desktop: 26.727.6591.0 x64
  • OS: Windows 10 Pro 22H2, build 19045.7548

Thread names, IDs, paths, and raw history are omitted because they contain private content.

Reproduction 1 — concurrent reads

At 2026-08-02T11:06:14.556Z, another active Codex task invoked codex_app__read_thread for nine existing threads concurrently through Promise.all. The oversized thread was one of them. Per-thread options included:

  • turnLimit: 3
  • includeOutputs: true
  • maxOutputCharsPerItem: 5000

For the oversized thread, Desktop routed the thread/read response after about 5988 ms. The tool call never received or persisted a matching custom_tool_call_output. The Desktop log cut off at 2026-08-02T11:06:21.252Z, and Windows destroyed the Codex AppX container at 2026-08-02T11:06:25.303Z.

Reproduction 2 — sequential read after restart

Codex relaunched at 2026-08-02T11:06:30.079Z. At 2026-08-02T11:08:06.233Z, the orchestration task retried with sequential reads. The oversized thread was first, now using:

  • turnLimit: 2
  • includeOutputs: false

Desktop again routed the same thread/read, this time after about 6023 ms. Again there was no matching tool result. The Desktop log ended at 2026-08-02T11:08:12.346Z, Windows destroyed the container at 2026-08-02T11:08:15.795Z, and the app relaunched at 2026-08-02T11:08:25.071Z.

Diagnostics

For both exits:

  • no normal quit/shutdown tail
  • no Windows Error Reporting or Application Error record
  • empty Crashpad reports directories
  • no Defender, resource exhaustion, power, or Codex deployment/update event
  • same Codex package version before and after
  • no process-termination command in surrounding tool calls

Implication

This is now a 2/2 repro across restart. The second run shows that includeOutputs: false and a small turnLimit do not protect the process; the first also had a per-item output cap. The likely failure boundary is before those response filters: read_thread appears to hydrate or serialize the complete ~970 MB rollout before producing the bounded response.

This extends the issue beyond ambient suggestions. Any agent or Desktop workflow that calls read_thread on an image-heavy historical thread can terminate the entire app, even when the caller explicitly requests no outputs.

A regression test should call read_thread(includeOutputs=false) on a very large rollout containing inline image data and require either:

  1. a bounded/lazy response, or
  2. a structured "thread too large" error,

without materializing the whole history across app-server/Desktop IPC.

This also reinforces #22004 and #28531. I can provide additional redacted timestamped extracts if useful.

matthewpenkala · 20 days ago

macOS reproduction: deterministic 2/2 read_thread main-process SIGTRAP on a 1.81 GiB image-heavy rollout

I can confirm the read_thread crash path on macOS with native crash evidence. This appears to bridge this issue's deterministic oversized-history trigger with the macOS CrBrowserMain signature tracked in #32676.

Environment

  • Unified ChatGPT/Codex desktop app: 26.803.41515 (build 6321)
  • Codex Framework: 151.0.7922.76
  • macOS: 26.5 (25F71)
  • Architecture: Apple Silicon / ARM64
  • Bundle ID: com.openai.codex
  • App was installed by Sparkle at approximately 15:32 local time on 2026-08-07.

Affected local history

  • Rollout JSONL size: 1,948,041,962 bytes (about 1.81 GiB)
  • JSONL records: 9,023
  • data:image occurrences: 1,129
  • input_image occurrences: 1,042
  • ;base64, markers: 1,127
  • Externalized generated-image directory: 90 files / about 192 MiB

The task ID, task title, prompts, local paths, and raw rollout are omitted because they contain private project material.

Deterministic reproduction

An agent in a different task called the built-in desktop thread reader twice with the same target:

{
  "threadId": "<redacted>",
  "turnLimit": 10,
  "includeOutputs": true,
  "maxOutputCharsPerItem": 20000
}
Run 1
  • Tool call began: 2026-08-07T22:33:41.152Z
  • Native crash captured: 2026-08-07 16:33:47.6755 -0600
  • Elapsed: approximately 6.5 seconds
  • Incident ID: 0AC1CCAA-A877-4D88-8C49-1BF696E7E07D
  • Crash report SHA-256: f5227e5ed2cad95f31c97967e4f3e274f4da6fa5ffc64cfb19e6ace92ec9a5fc
Run 2, after automatic relaunch
  • Tool call began: 2026-08-07T22:35:39.161Z
  • Native crash captured: 2026-08-07 16:35:46.1084 -0600
  • Elapsed: approximately 6.9 seconds
  • Incident ID: 981E98A6-DC42-40A9-B846-6EF962F29CDF
  • Crash report SHA-256: 04fb1a7391399117606dea7db0e0f2845c700ffc24321a3ee1c6b02b35524389

In both caller transcripts, the tool result was persisted as aborted by user after 6.5s / 6.9s, immediately followed by turn_aborted. No human cancellation occurred; those are downstream abort records created when the desktop host died.

Native crash signature, identical in both runs

process:        /Applications/ChatGPT.app/Contents/MacOS/ChatGPT
bundle:         com.openai.codex
exception:      EXC_BREAKPOINT
signal:         SIGTRAP
termination:    Trace/BPT trap: 5
faulting thread: CrBrowserMain / com.apple.main-thread
framework:      Codex Framework 151.0.7922.76

Both reports have the same leading framework offsets. The partially symbolicated leading sequence includes:

ares_llist_replace_destructor
ares_llist_replace_destructor
reading_mode$cxxbridge1$194$parse_distilled_html
reading_mode$cxxbridge1$194$parse_distilled_html
cppgc::internal::MakeGarbageCollectedTraitInternal::Allocate
node::PrincipalRealm::inspector_disable_async_hooks
v8::Isolate::Enter
v8::internal::MoveTracedReference
v8::internal::MoveTracedReference
v8::internal::MoveTracedReference

Crashpad independently created two sidecars at the exact incident times, both:

{"capture_kind":"crash","osarch":"arm64","ptype":"browser","ver":"151.0.7922.76"}

Alternative causes checked

  • No macOS jetsam or memory-pressure kill in the correlated unified logs.
  • Termination namespace is SIGNAL, by the process exception handler, rather than an OS resource kill.
  • Approximately 107 GiB disk space was available.
  • The installed bundle is validly signed by OpenAI team 2DC432GLL2.
  • /Applications/Codex.app is a symlink to /Applications/ChatGPT.app, not a competing second install.
  • The crashing process is the browser/main host, not the renderer, GPU process, or codex app-server.
  • The current framework has exactly two local Crashpad records; both are these reproduced browser crashes.

Why this adds new evidence

The prior deterministic reproduction in this issue established the oversized read_thread trigger on Windows without a Crashpad or WER record. This reproduction establishes the corresponding macOS native failure boundary:

  1. the same built-in thread read is deterministic 2/2;
  2. the target history is image-heavy and nearly twice the size of the prior 970 MB reproduction;
  3. both exits are genuine Chromium browser/main-process fatal traps;
  4. both share an identical native stack and occur approximately seven seconds after the read begins;
  5. the signature overlaps #32676, whose reports lacked a deterministic application-level trigger.

Requested fix / regression test

Please make read_thread operate on bounded, lazy history rather than hydrating or serializing the complete rollout before applying turnLimit, includeOutputs, and per-item output caps. A regression test should run read_thread against a multi-gigabyte image-heavy rollout and require either:

  • a bounded recent-tail response, or
  • a structured recoverable thread too large error,

without transferring the complete history across the app-server/Desktop IPC boundary and without terminating the browser/main process.

I can provide the two full .ips reports through a maintainer-designated private upload route. I am not attaching the raw rollout publicly because it contains private project content and inline image data.

boombx403-byte · 9 days ago

Hi @allvegetable, your report looks related to a local session discovery/inventory gap rather than necessarily a lost rollout. I've released Codex Rescue Alpha5, a local read-only diagnostic tool that performs filesystem-first discovery across active and archived rollouts and cross-references SQLite/index metadata without modifying any state.

If you still have the affected local Codex directory, you can inspect it via:

pip install codex-rescue==0.1.0a5
codex-rescue sessions --json

No raw files or databases are needed. If you choose to share output, please review and sanitize any private repository paths or names first.

shai347 · 9 days ago

New macOS reproduction on 26.814.41407: four main-process V8 OOM crashes after background read_thread

I can confirm that this bug is still happening on a newer macOS build. It crashed the full ChatGPT/Codex app four times on August 19 while I was working in other tasks. I did not click or open the oversized task. Background agents called the built-in codex_app__read_thread tool to review its history.

Environment

  • ChatGPT/Codex desktop app: 26.814.41407 (build 6720)
  • Codex Framework: 151.0.7922.137
  • macOS: 26.5.2 (25F84)
  • Apple Silicon / ARM64, Mac17,8
  • 64 GB RAM
  • In-app feedback ID: 019fef84-365a-79d3-80b4-6904ee87a749

Affected local history

  • Rollout JSONL size: 862,072,404 bytes (about 822 MiB)
  • JSONL records: 18,089
  • Inline data:image / ;base64, occurrences: 1,071
  • input_image occurrences: 935

The task title, task ID, local path, prompts, and raw history are omitted because they contain private work.

What happened

The first background task called read_thread five times. Early tool results reported original response sizes of approximately 581,900 and 671,708 tokens. The final read completed about 2.25 seconds before the app crashed.

A second background task reproduced the failure three more times:

  • One read_thread sequence completed about 0.91 seconds before the crash.
  • Another completed about 0.95 seconds before the crash.
  • In the final sequence, the agent reduced the requests to turnLimit values of 1, 2, 3, and 5, used includeOutputs: false, and reduced maxOutputCharsPerItem to 400, 300, 250, and finally 200. The app still crashed about 1.33 seconds after the last read completed.

This is important because it shows that small output limits do not protect the app. The desktop logs still show the full thread/turn response being handled before the small tool result is produced. It appears that the full history is hydrated or serialized before turnLimit, includeOutputs, and maxOutputCharsPerItem are applied.

Native crash evidence

All four macOS .ips reports show the same main-process failure:

process:         ChatGPT
bundle:          com.openai.codex
exception:       EXC_BREAKPOINT
signal:          SIGTRAP
faulting thread: CrBrowserMain / main thread
termination:     Trace/BPT trap: 5, by the app exception handler

Disassembly of the exact installed framework at the crash offset reaches ../../owl/common/node_bindings.cc and the fatal strings OOM detail: and OOM error in V8:. There was no macOS jetsam or system memory-pressure kill. This is an internal V8/Node memory failure in the desktop main process, not the Mac running out of its 64 GB of RAM.

Expected fix

Please make read_thread apply its limits before materializing or sending the complete historical thread. For a history this large, it should return a bounded recent page or a recoverable thread too large error. A background agent reading history in an unopened task should never be able to terminate the entire desktop app.

I have all four full .ips reports and can provide them through a private maintainer upload route if needed.

exevil · 8 days ago

Same failure on the current macOS build; adding a new feedback ID and exact-build evidence.

  • Feedback ID: 01a01b4f-7d3b-7c53-a790-01978c9ee9a8
  • ChatGPT/Codex Desktop: 26.814.41407 (build 6720)
  • Codex Framework: 151.0.7922.137
  • macOS 27.0 (26A5416b), Apple Silicon / MacBookPro18,4
  • Seven identical crashes on 2026-08-19. After the first crash, relaunches died within 39–103 seconds.
  • Signature: EXC_BREAKPOINT / SIGTRAP, CrBrowserMain / main thread, framework image offset 72598892 (0x453c56c).
  • Disassembly of the installed framework shows 0x453c56c is a brk #0 in the fatal handler referencing OOM error in V8 and OOM detail. V8/cppgc allocation frames precede it.
  • There was no macOS jetsam or system memory-pressure kill.

In this instance, app logs ended while several concurrent local/remote task streams and reasoning summaries were being rehydrated or multiplexed. I did not isolate an image-heavy rollout or a deterministic read_thread call, so I am reporting that trigger as correlated rather than proven. The identical current-build native signature suggests the same main-process V8 OOM failure family.

The full .ips reports are available through a private maintainer upload route if needed; they are not attached publicly because they may contain local paths.