›_ Codex Issues
Codex Issues / #37803

[Windows][Codex App] Huge patch_apply_end records inflate local Work session, cause blank screen, then crash/restart app

Open 💬 0 comments Opened Aug 10, 2026 by KhalidYS

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

ChatGPT/Codex unified desktop app 26.803.41515 on Windows 11

What subscription do you have?

Plus

What platform is your computer?

Windows 11 "Microsoft Windows NT 10.0.26200.0 x64"

What issue are you seeing?

<img width="1860" height="1140" alt="Image" src="https://github.com/user-attachments/assets/16eab16f-f647-47b3-90ee-f58dc23457e3" />

A single local Work conversation became impossible to open in the Windows desktop app.

When selecting the affected conversation:

  1. The conversation view first becomes completely blank.
  2. Shortly afterward, the desktop app crashes.
  3. The app then automatically restarts.

All other conversations continue to work normally.

Investigation

Affected thread ID:

019fcc1a-da8e-7682-bec7-823760949516

Local rollout:

%USERPROFILE%\.codex\sessions\2026\08\04\rollout-2026-08-04T12-28-59-019fcc1a-da8e-7682-bec7-823760949516.jsonl

The rollout had grown to 393.38 MB despite containing only 1,024 JSONL records.

Record-size analysis showed that almost the entire file was caused by only two records:

  • Line 776: 147.296 MB
  • Type: event_msg
  • Payload type: patch_apply_end
  • Line 1008: 240.589 MB
  • Type: event_msg
  • Payload type: patch_apply_end

Together, these two records accounted for approximately 98.6% of the entire session file.

Both were generated after patch/file operations involving generated .inspect.ndjson files. Each patch_apply_end event contained a very large changes payload.

The same session also contained V8/Node heap failures including:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

and:

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

Recovery test

The underlying conversation itself was still intact:

  • The JSONL remained structurally valid.
  • Thread metadata/index still existed.
  • The conversation history remained present.
  • The session ended with a valid task_complete event.

After creating a full backup, I created a repaired version of the rollout.

I preserved all 1,024 JSONL records, but replaced only the two oversized patch_apply_end records with compact valid equivalents preserving:

  • timestamp
  • type
  • call_id
  • turn_id
  • completion status

The huge changes payloads were removed.

The rollout size dropped from:

393.38 MB → 5.49 MB

All 1,024 JSONL records remained valid.

After replacing the live rollout with this repaired version, the exact same conversation immediately opened normally.

The following symptoms completely disappeared:

  • Blank conversation view
  • App crash
  • Automatic app restart

No changes were required to the thread index, global state, visualization directory, SQLite databases, or other application data.

This strongly suggests that reopening the Work thread causes the desktop client to load/process extremely large patch_apply_end payloads, eventually causing the renderer/app to fail.

What steps can reproduce the bug?

Feedback ID: no-active-thread-019fe690-d405-72b2-8781-548a01cdf109

What is the expected behavior?

patch_apply_end events should not embed unbounded file-change payloads directly into the local conversation rollout.

Large generated files, inspection data, deleted-file contents, or other large patch data should instead be:

  • Size-limited
  • Truncated
  • Summarized
  • Stored separately and referenced
  • Or otherwise prevented from creating extremely large individual JSONL records

A Work conversation should remain accessible regardless of the size of file operations performed during the session.

Even if a local session contains an unusually large event, opening the thread should not:

  • Blank the conversation UI
  • Crash the desktop application
  • Trigger an automatic application restart

The client should also handle oversized or malformed session events gracefully rather than making the entire local conversation inaccessible.

Additional information

Environment

  • OS: Windows 11
  • Client: ChatGPT/Codex unified desktop app
  • App version: 26.803.41515
  • Subscription: ChatGPT Plus
  • Thread type: Local Work conversation
  • Thread ID: 019fcc1a-da8e-7682-bec7-823760949516

Reproduction steps

  1. Open a local Work conversation in the Windows Codex/ChatGPT desktop app.
  1. Perform a large file-processing task involving generated files, spreadsheets, inspection data, or other substantial workspace operations.
  1. Allow Codex to perform patch/file operations, particularly deletion or modification of generated .inspect.ndjson files or similarly large generated files.
  1. Inspect the local conversation rollout under:

%USERPROFILE%\.codex\sessions\...

  1. Observe that event_msg records with payload type patch_apply_end may contain very large serialized changes payloads.
  1. In my affected session, two individual patch_apply_end records grew to:
  • 147.296 MB
  • 240.589 MB
  1. Close/reopen the conversation or navigate away and then select the affected Work conversation again.
  1. The conversation view becomes completely blank.
  1. Shortly afterward, the desktop application crashes.
  1. The application then automatically restarts.

Original affected rollout

  • Size: 393.38 MB
  • JSONL records: 1,024
  • Records >= 50 MB: 2

Largest records:

| Record | Size | Type | Payload |
|---|---:|---|---|
| Line 776 | 147.296 MB | event_msg | patch_apply_end |
| Line 1008 | 240.589 MB | event_msg | patch_apply_end |

These two records alone represented approximately 98.6% of the complete rollout file.

Repaired rollout

  • Size: 5.49 MB
  • JSONL records: 1,024
  • Invalid JSON records: 0
  • Conversation successfully opened after replacement
  • Blank screen disappeared
  • App stopped crashing/restarting

Only the two huge patch_apply_end payloads were reduced. The rest of the conversation was preserved.

Post-repair stress test

After another large Work task using 5.6 Sol Extra High reasoning lasting approximately 35 minutes:

  • Session size: 28.056 MB
  • Total JSONL records: 1,757
  • Records >= 5 MB: 2
  • Records >= 10 MB: 0

Largest newly generated records:

| Size | Type | Payload |
|---:|---|---|
| 8.89 MB | event_msg | patch_apply_end |
| 8.89 MB | event_msg | patch_apply_end |

Both belonged to the same task/turn.

This suggests that the issue is not simply caused by a long conversation. The abnormal growth appears specifically associated with large patch_apply_end change payloads.

Diagnostics available

I can provide sanitized diagnostic reports containing record sizes, event types, timestamps, call IDs, and turn IDs.

I have intentionally not attached the original 393 MB rollout because it contains private Work/project data.

The fact that reducing only the two oversized patch_apply_end events immediately restored the conversation provides a direct recovery/causality test.

Disclaimer

I am not a software developer or a technical expert. I diagnosed and recovered this issue with the assistance of ChatGPT.

The PowerShell diagnostic scripts, analysis of the local Codex session files, identification of the oversized patch_apply_end records, recovery procedure, and this GitHub report were all prepared with the help of ChatGPT.

I have tried to verify the results carefully by testing the repaired conversation and monitoring the session afterward, but some of the technical interpretation above is based on ChatGPT's analysis of the collected diagnostic data.

View original on GitHub ↗