macOS: compaction checkpoints re-embed screenshots until rollout hits 3.9 GB; ingestion then uses 10–20 GB RSS, causing jetsam kills and a kernel watchdog panic on a 16 GB Mac

What version of the Codex App are you using?

• Codex Desktop (macOS): 26.623.81905 (build 4598)
• codex-cli: 0.142.5
• macOS 26.5.1 (25F80), MacBook Air (Mac16,12, Apple Silicon, 16 GB RAM)

What platform is your computer?

macOS (Apple Silicon).

What issue are you seeing?

The root cause appears to be the same as #23257 (compaction checkpoints repeatedly re-embed full inline image payloads), but on macOS the consequence escalates beyond bloated files to system-wide crashes: jetsam kills of system daemons and eventually a kernel watchdog panic.

1. Rollout files snowball on disk

One long browser-automation session produced a single rollout JSONL of 3.9 GB:

• 29,406 records total; 98 compacted records account for 3.99 GB of the file
• compacted snapshot sizes grow monotonically: 0.1 MB → 3.4 MB → … → 53.4 MB each by the end of the session
• A sampled 42.8 MB compacted record contains 81 data:image base64 payloads (the same screenshots re-embedded on every compaction)
• Other sessions from the same week: 973 MB, 544 MB, 394 MB, 254 MB, 231 MB; ~/.codex totaled 10 GB (logs_2.sqlite alone 721 MB)

2. Session ingestion then uses 10–20 GB RSS

macOS resource-exceedance reports (Microstackshots) for the codex process show repeated memory explosions from a ~100 MB baseline while a sqlx/SQLite thread spins in sqlite3_step / sqlite3_wal_checkpoint_v2 / pwrite:

• Footprint: 98.66 MB -> 6167.55 MB (+6068.89 MB) (max 12.19 GB) within a 7.5-minute sample window
• Footprint: 104.02 MB -> 6774.80 MB (+6670.78 MB) (max 11.81 GB) (different pid, same day)
• Five separate "disk writes" resource-exceedance reports over 3 days with the same stack signature (~10.5 MB written per sample step)

3. System impact on a 16 GB Mac

• A JetsamEvent-*.ips report names largestProcess: codex at 15.5 GB RSS (lifetimeMax 20.5 GB) while macOS jettisoned dozens of system daemons
• The following night: kernel panic — watchdog timeout: no checkins from watchdogd in 90 seconds. The panic snapshot shows codex at 10.7 GB RSS, compressor 12.2 GB, 0.01 GB free
• Collateral during the week: a WindowServer userspace watchdog timeout (forced session restart) and bursts of Chrome renderer crashes (abort traps) under memory pressure

What steps can reproduce the bug?

1. On a 16 GB Mac, run a long Codex session that uses browser/screenshot tools heavily, long enough to cross many automatic compactions.
2. Inspect the session rollout JSONL: each new compacted record re-embeds prior screenshots as inline base64, so checkpoints grow roughly linearly and the file quadratically.
3. Leave the desktop app running: when codex (re)ingests the rollout into SQLite, RSS climbs to 10–20 GB → jetsam kills → possible watchdog kernel panic overnight.

What is the expected behavior?

• compacted checkpoints should deduplicate or reference image payloads instead of re-embedding them (as proposed in #23257), and superseded checkpoints should be pruned.
• Rollout/session ingestion should stream with bounded memory instead of holding multi-GB parsed history resident.

Related: #23257 (compaction re-embeds images, Windows), #24676 (desktop hangs opening image-heavy rollout), #24550.

Happy to attach sanitized excerpts of the resource reports, jetsam event, or panic log on request.