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

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

1. Run a long local task.
2. Delete a very large file through an apply_patch Delete File operation.
3. The resulting patch_apply_end event includes the deleted file's entire contents:

payload.changes.<path>.content.

1. Archive or otherwise leave the task, then select/open it again.
2. 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_end deletion 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_started
• 00:15:13.069Z: thread/read returned successfully
• 00:15:16.203Z: thread/resume returned successfully
• 00:15:21.976Z: final log entry from that app process
• 00: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.*.content values 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

1. Add a byte cap before serializing deleted-file content into patch_apply_end.
2. Enforce per-record and per-field size limits when reading legacy JSONL histories.
3. Avoid transferring giant patch payloads to the renderer.
4. Add a fallback placeholder such as “deleted file content omitted: N bytes”.