Pro plan unusable: lossy compaction silently rewrites instructions + unreapable subagent leak (5 compounding bugs, full telemetry)

Summary

I am a ChatGPT Pro subscriber ($200/month). After a single real-world work session, Codex became effectively unusable due to five separate, already-open bugs compounding at once. This report adds a fully instrumented field case to those issues, because individually they are reported as edge cases — together they make multi-hour, multi-agent work impossible on the paid tier.

I am not reporting "the model is dumb." The model (GPT-5.x) understood every task correctly before compaction. The failures are product-level: lossy compaction, post-compaction amnesia, and a subagent leak that cannot be cleared.

Environment

• Plan: ChatGPT Pro ($200/mo)
• Platform: macOS (Darwin 25.5.0, Apple Silicon)
• Interface: Codex App + CLI, multi-agent (spawn_agent) enabled
• config.toml: [agents] max_threads = 12, job_max_runtime_seconds = 1800

Measured telemetry (single session)

Extracted directly from the session rollout .jsonl:

| Metric | Value |
|---|---|
| Session duration | ~12 h (one continuous thread) |
| Rollout size on disk | 266 MB |
| Cumulative tokens | 127,482,242 |
| Auto-compaction events | 9 |
| spawn_agent calls | 109 |
| close_agent calls | 110 (mostly failing — see below) |
| exec_command calls | 704 |
| Subagents stuck "shutdown", not closable | ~70 |

What actually happened (reproducible failure chain)

1. Lossy compaction silently rewrote my instructions (cf. #18720, #5957)
I asked for raster/generated images for hero/section mockups. After compaction, the agent produced SVG instead — because an earlier instruction in the same session ("stop generating images, use existing assets") survived the summary while my latest explicit instruction was diluted. The model was not disobeying; the compaction summary changed the task. The reverse also happened (unwanted generated images of "people in front of computers" when I never asked).

2. Per-page constraints were lost (cf. #14347)
I explicitly required "each page must have its own data." A shared data factory produced identical images and identical thin content across all pages. After several compactions the model no longer held this constraint. I hit 9 compactions — squarely in the "degraded" band documented in #14347 (9+ = even cumulative summaries get compressed).

3. Subagent leak I could not clear (cf. #23219, #23700, #23749)
~70 subagents appeared as shutdown in the sidebar but kept counting toward the spawn limit. close_agent failed with thread not found. The model was forced to map 70 thread IDs from ~/.codex/sessions and archive them by hand via set_thread_archived. Of 109 spawns, the vast majority were never reaped automatically.

4. App freezes at the compaction threshold (cf. #19116)
Repeated UI freezes occurred exactly when the context approached the auto-compaction threshold.

Why this is unacceptable on a paid plan

• These are not obscure edge cases. They are the default outcome of any session longer than ~2-3 hours with multi-agent enabled.
• The official guidance ("one session = one task, restart Codex when an agent goes stale") is a manual workaround for product defects, not a feature. A $200/mo product should not require the user to babysit context-window accounting and manually archive zombie threads.
• The compounding is the core issue: compaction loses intent → user re-instructs → more agents spawned → leak worsens → freeze → work exceeds the next compaction window → loop. A single 12h session burned 127M tokens largely re-doing work erased by compaction.

What I am asking for

1. Deterministic compaction checkpoint instead of a lossy narrative summary (the RFC in #8573 is the right direction): preserve current objective, accepted scope, files changed, and the latest explicit user constraints verbatim.
2. close_agent must be idempotent and shutdown/nonexistent agents must not count toward the spawn limit (#23219).
3. Auto-reap completed subagents and release their resources/quota (#23749, #23700).
4. Do not freeze at the compaction threshold (#19116).
5. At minimum, a visible, manual "compact now with these pinned constraints" control so users can protect critical instructions before the window fills.

Related issues

#18720 · #5957 · #14347 · #23219 · #23700 · #23749 · #19116 · RFC #8573

Happy to provide the (redacted) rollout .jsonl and per-event timestamps to the maintainers.