9.47M tokens + 183.9M cached in one 5.9h CLI session: 74 compactions sustained ~every 3.7min, 95% followed by re-reading files/tests already read this session

Start with the rollout JSONL at ~/.codex/sessions/2026/08/02/rollout-2026-08-02T14-34-59-019fc42f-e008-79e2-9d11-b7a5b2eb7f43.jsonl, inspecting event_msg.type=token_count, event_msg.type=context_compacted, and response_item entries. Run the long-session reproduction outline and compare compaction frequency with repeated file reads, test runs, and cached_input_tokens; done means the repeated post-compaction work is addressed and the behavior is visible in session diagnostics.

What version of Codex are you using?

• Product: Codex CLI (TUI)
• Codex CLI: 0.146.0
• Model: gpt-5.5
• Approval policy: never
• Filesystem sandbox: danger-full-access
• Session: 019fc42f-e008-79e2-9d11-b7a5b2eb7f43 (resumable via codex resume 019fc42f-e008-79e2-9d11-b7a5b2eb7f43)
• Observed: 2026-08-02/03

Summary

A single 5.9-hour CLI session (20:39:03Z to 02:32:57Z) accumulated 9,469,686 total tokens (8,416,873 input, 1,052,813 output) plus 183,934,336 cached-input tokens across 2,607 model turns. Analysis of the session rollout JSONL shows this was not driven by legitimate work volume — it was driven by a sustained compact → forget → re-fetch → refill → compact cycle.

The session underwent 74 context-compaction events, averaging one every 3.7 minutes (median 192s), sustained essentially unchanged from the first 10 minutes of the session through the last 10 minutes (min gap 74s, max gap 522s) — i.e. this was not a one-time startup burst, it was the session's steady state for its entire duration.

70 of the 74 compactions (95%) were followed within 2 minutes by the agent re-reading a file it had already read earlier in the session, or re-running a test command it had already run (99% within 5 minutes). A handful of large source files were each re-fetched via Get-Content between 6 and 25 times over the session (e.g. one ~40K-line-count React component was read 9 separate times; one API route file was read 25 times across quoting variants; a browser-debug JS file was read 17 times), and two test commands were re-run 11 and 7 times respectively with no edits visible in between several of the repeats.

Net effect measured directly from the transcript: of the ~24.2M characters of accumulated tool-output content in this session, 89.8% is function_call_output (tool/shell results), and within that, 119 individual command outputs hit a ~40,000-character truncation ceiling — meaning the real output was even larger before Codex's own truncation cut it. Only ~1.2% of total accumulated content was session-startup/hook boilerplate; the overwhelming majority is this re-read/re-run pattern.

Why this looks like a Codex-side bug, not agent misbehavior

The agent had no way to know a compaction had just discarded the specific fact "I already have the full content of file X in context" — nothing in the post-compaction context appears to preserve that as retrievable state, so the very next action is almost always to re-fetch exactly what was just summarized away. Each re-fetch (large file, or large test output) is itself big enough to immediately re-trigger compaction, producing a self-sustaining loop for the session's entire 5.9-hour lifetime rather than compaction ever actually relieving context pressure.

This compounds directly into the cached-token bill: the same re-created content gets resent and cache-hit on every one of the following turns until it next ages out, so (large, repeatedly-recreated context) × (2,607 turns) is what produces the 183.9M cached-token total.

Reproduction outline

1. Start a long CLI session in a large monorepo workspace doing iterative file-editing/testing work on a handful of sizeable source files (>1000 lines) with a full test suite that produces large (>20K char) output.
2. Let the session run long enough to trigger repeated context compaction (in this case, every ~3-4 minutes sustained).
3. Observe: does the agent re-fetch full file contents / re-run full test output shortly after each compaction, for files/commands it had already fetched/run earlier in the same session?
4. Compare cumulative cached_input_tokens growth rate against the compaction frequency.

Suggested fix directions

• Compaction summaries should retain (or make cheaply re-derivable without a full re-fetch) a manifest of "files/commands already fully read this session and their content hash/location," so the agent can recognize it already has the data rather than re-fetching wholesale.
• Consider a per-session dedup/cache layer for large tool outputs (keyed by exact command + file mtime) so an identical re-fetch after compaction is served from a lightweight reference instead of a full re-execution and full re-billing.
• Surface compaction frequency (and pre/post compaction token deltas) in codex resume/session diagnostics so this pattern is visible without post-hoc JSONL analysis.

Data used for this report

Derived from the session's own rollout log (~/.codex/sessions/2026/08/02/rollout-2026-08-02T14-34-59-019fc42f-e008-79e2-9d11-b7a5b2eb7f43.jsonl, 16,456 lines / 49MB) — event_msg.type=token_count for cumulative usage, event_msg.type=context_compacted for the 74 compaction timestamps, and response_item entries for the re-read/re-run correlation. Happy to attach the raw analysis script or specific excerpts if useful.