Codex desktop crashes when opening a thread with a 203 MB patch_apply_end deletion event

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

• #31583

Powered by Codex Action

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

• Device: MacBook Pro 14-inch
• Chip: Apple M5
• Unified memory: 24 GB
• Operating system during the incident: macOS Tahoe 26.5.2
• ChatGPT desktop build: 26.727.40816
• Bundled Codex app-server: 0.146.0-alpha.9.2

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.

• Restarting the Mac did not resolve the problem.
• Reinstalling the desktop application did not resolve the problem.
• The application failed during 34 consecutive startup attempts.
• Moving the affected session JSONL file out of ~/.codex/sessions immediately stopped the crash loop.
• Other conversations continued to work normally.

Session analysis

The affected session file was syntactically valid JSONL:

• File size: 584,249,672 bytes
• Records: 4,577 valid JSONL records
• patch_apply_end events: 112
• Serialized content in those patch events: approximately 553.6 MB, representing about 94.8% of the complete session
• Largest individual JSONL record: approximately 194.3 million characters

The oversized events contained complete contents of temporary .xlsx.inspect.ndjson files under:

changes.<path>.content

The final turn was aborted and left the recorded turn/item state inconsistent.

During every failed startup:

1. maybe_resume_started was recorded.
2. thread/read completed successfully.
3. The application encountered an Item not found in turn state condition.
4. maybe_resume_success was never reached.
5. The desktop process terminated approximately 10–15 seconds later.

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:

• removing the oversized patch_apply_end events;
• removing the incomplete final turn;
• preserving the 20 completely finished turns.

Results:

• Repaired session size: 28,570,661 bytes
• Turn state: 20 started and 20 completed turns
• No remaining aborted turn
• No remaining reference to the missing item
• The repaired conversation could be opened successfully using codex fork

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:

1. unbounded serialization of complete file contents in patch_apply_end events;
2. unsafe hydration or resume behavior when the final turn contains inconsistent or missing item state;
3. failure to quarantine or skip an unreadable session, resulting in a persistent application startup crash loop.

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:

• remote triggering;
• arbitrary code execution;
• privilege escalation;
• access to unrelated files;
• data exfiltration.

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

• Large file contents should be omitted, truncated or stored by reference in patch events.
• Session hydration should tolerate missing items and incomplete final turns.
• One malformed or oversized thread should not terminate the complete desktop application.
• After a failed resume attempt, the application should disable automatic reopening of that thread.
• The application should offer a safe-mode or quarantine recovery option.
• A maximum session and individual-record size should be enforced before hydration.

Related reports

• https://github.com/openai/codex/issues/32904
• https://github.com/openai/codex/issues/24263
• https://github.com/openai/codex/issues/24948

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.