Codex App restarts when session history captures large binary FileChange bodies

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

26.908.70816 (build 9275)

What subscription do you have?

Pro x20

What platform is your computer?

Darwin 25.6.0 arm64 arm

What issue are you seeing?

Opening one Codex Desktop thread repeatedly restarts the UI. Navigating to the thread reports success, but the thread read API fails with: MCP error -32000: Codex app tool request failed.

Local session inspection found one JSONL session at 249,311,394 bytes. It contained 56 FileChange records for temporary .b64 files with raw changes.<path>.content bodies persisted inline.

• Total raw Base64 length: 128,174,948 characters
• Largest single body: 28,662,741 characters
• Additional inline binary payloads: 22 structured-result Base64 fields and 46 screenshot data URLs

This causes the desktop app to hydrate/render enormous binary payloads from task history.

What steps can reproduce the bug?

1. Run a Codex task that downloads or writes many binary attachments through temporary .b64 files.
2. Let FileChange history capture each file's raw content inline.
3. Accumulate a large local session (this case: 249 MB).
4. Open that task from Codex Desktop history.

Actual: Codex Desktop UI repeatedly restarts; thread read API also fails.

What is the expected behavior?

Binary artifacts should be stored out of line and history should keep only metadata or a deduplicated reference: path, MIME type, size, checksum, and blob/object key. FileChange events, tool outputs, and compacted history should not inline raw binary/Base64. The UI should cap or lazy-load large event bodies.

For recovery, I backed up the original local session and removed only binary/Base64 bodies. Size fell from 249 MB to 98.6 MB. Remaining large content is Gmail read_email text, not binary.

Additional information

No response

Start by reproducing the failure with the 249 MB local session and inspect how FileChange records, tool outputs, and compacted history persist and hydrate binary/Base64 bodies. Done means large binary artifacts are kept out of line or referenced by metadata, and opening the affected history no longer restarts the UI or fails the thread read API.