Repository navigation
Codex desktop crashes when opening a thread with a 203 MB patch_apply_end deletion event #32904
Description
Summary
On Windows, opening a long-running local task causes the entire Codex desktop app to terminate and restart. The task archive itself remains intact.
The strongest causal evidence is a single oversized patch_apply_end history record produced when apply_patch deleted a large JSON file. The event serialized the deleted file's full contents under changes.<path>.content, creating one 203,310,615-character JSONL record. Loading/resuming that task appears to exhaust the desktop renderer or main process.
Environment
- Codex desktop package:
OpenAI.Codex 26.707.8479.0 - Desktop release in logs:
26.707.62119 - Current Codex CLI/app-server:
0.144.2 - Problematic session was originally written by:
0.144.0-alpha.4 - Windows x64 build:
26200.8655
Reproduction characteristics
- Run a long local task.
- Delete a very large file through an
apply_patchDelete Fileoperation. - The resulting
patch_apply_endevent includes the deleted file's entire contents:
payload.changes.<path>.content. - Archive or otherwise leave the task, then select/open it again.
- The desktop app terminates and restarts while hydrating the history.
I have not included the deleted file or any user paths. The file was JSON, but its specific contents do not appear relevant.
Measured archive data
- Archive size: 302,158,899 bytes
- JSONL records: 24,851
- Largest record: 203,310,615 characters
- Records >= 1 MB: 30
- Records >= 10 MB: 1
- Records >= 100 MB: 1
- The sole record above 10 MB is the
patch_apply_enddeletion event. - Thread lifetime was roughly 24 hours and accumulated about 697 million token-usage counts, but the singular 203 MB deletion event is the clear outlier.
The next-largest record was about 4.7 MB and contained a base64 image.
Crash timeline
Desktop log timestamps:
00:15:13.061Z:maybe_resume_started00:15:13.069Z:thread/readreturned successfully00:15:16.203Z:thread/resumereturned successfully00:15:21.976Z: final log entry from that app process00:15:28Z: new desktop process/log session started
There is no normal exception, Windows Error Reporting entry, or Crashpad dump for the termination. That abrupt boundary is consistent with memory exhaustion or a hard process kill during history hydration/rendering.
Expected behavior
- Patch history should not embed unbounded deleted-file contents.
- Large
changes.*.contentvalues should be omitted, capped, summarized, or stored out of line. - The desktop app should truncate or virtualize oversized history items rather than terminating.
- If a task cannot be rendered, the UI should show a recoverable error and allow export/repair.
Actual behavior
Selecting the task reliably causes the whole desktop app to exit and restart, making the task unopenable from the UI.
Suggested safeguards
- Add a byte cap before serializing deleted-file content into
patch_apply_end. - Enforce per-record and per-field size limits when reading legacy JSONL histories.
- Avoid transferring giant patch payloads to the renderer.
- Add a fallback placeholder such as “deleted file content omitted: N bytes”.
Activity
github-actions commentedon Jul 14, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
s4kwskrrbb-dev commentedon Jul 31, 2026
macOS reproduction: 584 MB session with oversized patch_apply_end payloads causes a persistent desktop crash loop
I can confirm a closely matching failure mode on macOS. This provides a cross-platform reproduction of the behavior reported in issue #32904.
Environment
No serial number, account identifier or complete local user path is included in this report.
macOS update context
macOS Tahoe 26.6 was released on July 27, 2026 and had therefore been available for only four days when this incident was investigated.
The decisive isolation test was performed on macOS 26.5.2. During that test, the only change was moving one affected session JSONL file out of the active sessions directory. The crash loop stopped immediately.
This demonstrates that updating macOS was not required to stop the observed crash. I am not claiming that macOS 26.5.2 caused the failure.
The original affected session has not been deliberately reopened under macOS 26.6, because restoring it to the active session directory may recreate the persistent startup crash loop.
Actual behavior
The ChatGPT desktop app repeatedly terminated approximately 10–15 seconds after startup while attempting to resume one particular Codex thread.
Session analysis
The affected session file was syntactically valid JSONL:
The oversized events contained complete contents of temporary .xlsx.inspect.ndjson files under:
changes..content
The final turn was aborted and left the recorded turn/item state inconsistent.
During every failed startup:
The available application logs did not contain an explicit out-of-memory exception or another clearly identified fatal exception.
Recovery and isolation test
I created a cleaned copy of the session by:
Results:
The project directory and Mac hardware remained unchanged. The application worked once the affected session was removed and the cleaned copy could be read successfully.
Technical assessment
This does not appear to be ordinary insufficient system memory. The Mac has 24 GB of unified memory and the application operates normally after the single affected session is removed.
Temporary memory amplification while parsing, decoding and rendering an individual record of approximately 194 million characters may nevertheless have caused the final process termination.
The underlying defects appear to be:
Potential security relevance
At minimum, this is a persistent local application-level denial-of-service condition.
If untrusted repository content, documents or tool output can deliberately cause an oversized session to be serialized, a malicious actor may potentially be able to force the application into a repeatable crash loop.
That attack path has not been demonstrated in this case. I have not observed:
I am not publishing a crafted malicious session or instructions for deliberately triggering the condition. More detailed diagnostic material can be shared privately if required.
Expected behavior
Related reports
Sanitized log excerpts and the original thread identifier can be provided through a private support or security-reporting channel if required. The complete raw session will not be uploaded publicly.