›_ Codex Issues
Codex Issues / #27131

Codex self-ingests local session JSONL logs during token-usage investigation, causing runaway token growth

Open 💬 7 comments Opened Jun 9, 2026 by tutadeploy
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

Codex self-ingests local session JSONL logs during token-usage investigation, causing runaway token growth

What subscription do you have?

ChatGPT Pro

What platform is your computer?

_No response_

What issue are you seeing?

Title: Codex self-ingests local session JSONL logs during token-usage investigation, causing runaway token growth

Summary

I encountered a runaway token growth issue in Codex App / Codex CLI.

The conversation was very short and simple: I only asked a few short questions about why my Codex token usage seemed abnormally high. However, the current Codex session rapidly accumulated more than 1.2 million total tokens within a few minutes.

After inspecting the local Codex session JSONL metadata, the issue appears to be caused by Codex reading and searching its own local session transcript files under ~/.codex/sessions and ~/.codex/archived_sessions. These large rollout JSONL files were then returned as tool outputs and injected back into the active conversation context, causing a self-amplifying token growth loop.

Environment

  • Product: Codex App / bundled Codex CLI
  • Codex CLI version: codex-cli 0.137.0-alpha.4
  • OS: macOS
  • Local project: ai-h5-editor
  • Repository complexity: normal local Git repository, not a large or unusual codebase
  • Relevant session file: ~/.codex/sessions/2026/06/09/rollout-2026-06-09T13-30-58-<redacted>.jsonl

Observed behavior

The Codex session accumulated approximately 1,239,690 total tokens.

This was not a single 1.2M-token context window. Instead, Codex repeatedly invoked the model many times in a short period. The per-turn input grew from around 23k tokens to more than 100k tokens.

Token timeline extracted from the session JSONL:

line 11   last_input=23021    last_output=194    last_cached=4608     last_total=23215
line 23   last_input=23258    last_output=876    last_cached=4608     last_total=24134
line 27   last_input=24191    last_output=446    last_cached=23168    last_total=24637
line 38   last_input=23564    last_output=400    last_cached=23168    last_total=23964
line 44   last_input=34771    last_output=259    last_cached=23424    last_total=35030
line 48   last_input=35075    last_output=333    last_cached=34688    last_total=35408
line 63   last_input=34674    last_output=909    last_cached=23552    last_total=35583
line 67   last_input=48763    last_output=587    last_cached=34560    last_total=49350
line 73   last_input=49399    last_output=468    last_cached=48640    last_total=49867
line 77   last_input=51548    last_output=488    last_cached=49280    last_total=52036
line 89   last_input=52651    last_output=1044   last_cached=51456    last_total=53695
line 93   last_input=101410   last_output=543    last_cached=52608    last_total=101953
line 97   last_input=102007   last_output=320    last_cached=101376   last_total=102327
line 109  last_input=102376   last_output=1282   last_cached=101888   last_total=103658
line 113  last_input=103846   last_output=130    last_cached=102272   last_total=103976
line 117  last_input=104025   last_output=1353   last_cached=103808   last_total=105378
line 121  last_input=105740   last_output=1431   last_cached=103936   last_total=107171
line 138  last_input=101485   last_output=651    last_cached=34560    last_total=102136
line 152  last_input=105490   last_output=682    last_cached=101376   last_total=106172

Final cumulative usage:
total_input=1227294
total_output=12396
total_cached=1022976
total_total=1239690

The suspicious jump happened around line 89 to line 93, where last_input increased from roughly 52k to roughly 101k.

Root cause evidence

The session JSONL shows that Codex decided to inspect previous Codex sessions while investigating token usage.

Codex emitted an assistant message equivalent to:

I already have the cumulative token leaderboard. Next I will look at the context of the largest sessions to confirm whether a tool loop, long file, or log reading caused the spike.

Immediately after that, Codex executed commands that directly printed parts of local rollout JSONL transcript files:

sed -n '1,80p' ~/.codex/sessions/2026/06/09/rollout-2026-06-09T03-02-16-<redacted>.jsonl
sed -n '1,80p' ~/.codex/sessions/2026/06/09/rollout-2026-06-09T03-00-08-<redacted>.jsonl
sed -n '1,80p' ~/.codex/sessions/2026/06/09/rollout-2026-06-09T01-31-17-<redacted>.jsonl
sed -n '1,120p' ~/.codex/sessions/2026/06/09/rollout-2026-06-09T13-30-58-<redacted>.jsonl

The corresponding tool outputs reported very large original token counts:

line 85: Original token count: 71367
line 86: Original token count: 108279
line 87: Original token count: 57599
line 88: Original token count: 52330

These four log-reading commands alone represented approximately 289,575 original output tokens before truncation.

Later, Codex also executed a broad ripgrep command over ~/.codex:

rg -n "workspace|api|baseUrl|base_url|model|provider|auth|echo|bird|proxy|OPENAI|headroom|mode|instruct" ~/.codex -g 'config*' -g '*.json*'

The glob *.json* matched .jsonl files, not only .json config files. In my local environment, this matched many Codex transcript files:

matched_jsonl_files=118
matched_json_files=525
matched_config_files=168

jsonl_files=118
json_files=525
session_files=86
log_files=0
config_named_files=168

The corresponding tool output reported an extremely large original token count:

line 148: Original token count: 23563888

This suggests that Codex unintentionally searched large local transcript files while trying to inspect configuration-related data.

File-size evidence

A size-only scan showed that the largest matched files were mostly Codex session or archived session JSONL files:

19.99 MB  sessions    ~/.codex/sessions/2026/05/22/rollout-2026-05-22T00-59-18-<redacted>.jsonl
17.46 MB  sessions    ~/.codex/sessions/2026/05/22/rollout-2026-05-22T21-38-25-<redacted>.jsonl
12.85 MB  archived    ~/.codex/archived_sessions/rollout-2026-05-19T18-14-46-<redacted>.jsonl
10.95 MB  archived    ~/.codex/archived_sessions/rollout-2026-05-20T18-04-06-<redacted>.jsonl
9.82 MB   archived    ~/.codex/archived_sessions/rollout-2026-06-08T03-13-51-<redacted>.jsonl

This confirms that broad searches under ~/.codex can easily include large historical Codex transcripts.

Why this is problematic

This behavior is surprising and potentially costly because the user did not ask Codex to ingest full historical transcripts.

The agent selected broad shell commands that caused its own local session logs to be read and then included as tool outputs in the current session context.

This creates a feedback loop:

  1. User asks why token usage is abnormally high.
  2. Codex searches local Codex session logs.
  3. Large rollout JSONL transcripts are printed as tool output.
  4. Tool output enters the active conversation context.
  5. Token usage increases rapidly.
  6. Further investigation reads even more logs.
  7. The token usage issue becomes self-amplifying.

Expected behavior

Codex should avoid directly printing or ingesting its own local session transcript files when diagnosing token usage, session history, or configuration.

Specifically, Codex should not run raw cat, sed, head, tail, jq, or broad rg commands over:

$CODEX_HOME/sessions/**
$CODEX_HOME/archived_sessions/**
~/.codex/sessions/**
~/.codex/archived_sessions/**
rollout-*.jsonl

unless the user explicitly requests a tiny bounded excerpt.

Codex should also avoid broad globs such as:

-g '*.json*'

when searching ~/.codex, because this matches .jsonl transcript files.

Actual behavior

Codex directly read and searched local rollout JSONL transcript files. These large transcript outputs were then injected into the active conversation as tool outputs, causing rapid cumulative token growth and per-turn input growth.

Suggested fixes

Please consider adding built-in guardrails against self-log ingestion.

Possible mitigations:

  1. Treat Codex session transcripts as high-risk files.
  2. Require explicit user approval before printing raw rollout-*.jsonl content.
  3. Automatically exclude session directories from broad config searches:
  • $CODEX_HOME/sessions/**
  • $CODEX_HOME/archived_sessions/**
  • ~/.codex/sessions/**
  • ~/.codex/archived_sessions/**
  1. Warn or block commands that target rollout-*.jsonl with cat, sed, head, tail, jq, or rg.
  2. Replace raw transcript inspection with safe metadata-only diagnostics:
  • file size
  • line count
  • event type counts
  • token_count fields
  • function_call command names
  • function_call_output original token counts
  1. When searching configuration, prefer:

``bash
-g '*.json'
``

instead of:

``bash
-g '*.json*'
``

  1. Provide a safe built-in Codex diagnostic command for token usage that extracts only metadata and token-count fields.

Local workaround

I plan to add a local rule telling Codex not to directly print or search raw rollout JSONL files, and to exclude session directories when searching configuration.

Safer search pattern:

rg -n "workspace|api|baseUrl|base_url|model|provider|auth|proxy|OPENAI|mode|instruct" ~/.codex \
  -g 'config*' \
  -g '*.json' \
  -g '!sessions/**' \
  -g '!archived_sessions/**'

This reduces the risk, but the underlying behavior still seems like Codex should have a built-in guardrail.

Privacy note

I am intentionally not attaching the full raw rollout JSONL files in this initial report because they may contain private prompts, local paths, command outputs, and project details.

I can provide sanitized excerpts if needed, including:

  • token_count timeline
  • function_call command list
  • function_call_output original token counts
  • file-size summaries

What steps can reproduce the bug?

Steps to reproduce:

  1. Use Codex App with bundled Codex CLI version codex-cli 0.137.0-alpha.4 on macOS.
  2. Have existing Codex session history under ~/.codex/sessions/** and ~/.codex/archived_sessions/**.
  3. Start a normal Codex conversation in a local Git repository.
  4. Ask Codex a short question about abnormal token usage / why a Codex session consumed many tokens.
  5. Codex may decide to inspect its own local session JSONL files.
  6. In my observed session, Codex executed commands like:
sed -n '1,80p' ~/.codex/sessions/2026/06/09/rollout-2026-06-09T03-02-16-<redacted>.jsonl
sed -n '1,80p' ~/.codex/sessions/2026/06/09/rollout-2026-06-09T03-00-08-<redacted>.jsonl
sed -n '1,80p' ~/.codex/sessions/2026/06/09/rollout-2026-06-09T01-31-17-<redacted>.jsonl
sed -n '1,120p' ~/.codex/sessions/2026/06/09/rollout-2026-06-09T13-30-58-<redacted>.jsonl
  1. Later, Codex also executed a broad config search:
rg -n "workspace|api|baseUrl|base_url|model|provider|auth|echo|bird|proxy|OPENAI|headroom|mode|instruct" ~/.codex -g 'config*' -g '*.json*'
  1. The glob *.json* matched .jsonl session transcript files, not only config JSON files. This caused Codex to search large historical transcript files and inject their output into the active conversation as tool output.

Observed session:

  • Session file: ~/.codex/sessions/2026/06/09/rollout-2026-06-09T13-30-58-019eaadc-d12d-7f33-84e8-cd56bba38544.jsonl
  • Session id from filename: 019eaadc-d12d-7f33-84e8-cd56bba38544
  • Codex CLI version: codex-cli 0.137.0-alpha.4
  • Final cumulative token usage observed:
  • total_input=1227294
  • total_output=12396
  • total_cached=1022976
  • total_total=1239690

Observed context/token growth from token_count events:

line 11   last_input=23021    last_output=194    last_cached=4608     last_total=23215
line 23   last_input=23258    last_output=876    last_cached=4608     last_total=24134
line 67   last_input=48763    last_output=587    last_cached=34560    last_total=49350
line 89   last_input=52651    last_output=1044   last_cached=51456    last_total=53695
line 93   last_input=101410   last_output=543    last_cached=52608    last_total=101953
line 121  last_input=105740   last_output=1431   last_cached=103936   last_total=107171
line 152  last_input=105490   last_output=682    last_cached=101376   last_total=106172

The largest observed per-turn input was approximately 105,740 input tokens, and the largest observed per-turn total was approximately 107,171 tokens.

Tool-output evidence:

The direct sed commands over local rollout JSONL files produced very large original tool outputs:

line 85: Original token count: 71367
line 86: Original token count: 108279
line 87: Original token count: 57599
line 88: Original token count: 52330

The broad rg command over ~/.codex produced an extremely large original output estimate:

line 148: Original token count: 23563888

Local file matching evidence:

matched_jsonl_files=118
matched_json_files=525
matched_config_files=168

jsonl_files=118
json_files=525
session_files=86
log_files=0
config_named_files=168

Expected behavior:

Codex should not directly print or ingest its own session transcript files when diagnosing token usage or configuration. It should avoid raw cat, sed, head, tail, jq, or broad rg commands over:

$CODEX_HOME/sessions/**
$CODEX_HOME/archived_sessions/**
~/.codex/sessions/**
~/.codex/archived_sessions/**
rollout-*.jsonl

Codex should also avoid broad globs such as *.json* when searching ~/.codex, because this matches .jsonl transcript files.

Actual behavior:

Codex read and searched its own local rollout JSONL transcript files. The outputs were returned as tool outputs and then included in the active conversation context, causing runaway cumulative token growth.

Impact:

A short conversation about token usage grew to over 1.2M cumulative tokens. This appears to be a self-log-ingestion / recursive context growth issue.

Suggested fix:

Please consider adding a guardrail to prevent Codex from ingesting its own session logs. A safer default would be to exclude:

~/.codex/sessions/**
~/.codex/archived_sessions/**

from broad config searches, and to require explicit user approval before printing raw rollout-*.jsonl transcript content.

A safer config search pattern would be:

rg -n "workspace|api|baseUrl|base_url|model|provider|auth|proxy|OPENAI|mode|instruct" ~/.codex \
  -g 'config*' \
  -g '*.json' \
  -g '!sessions/**' \
  -g '!archived_sessions/**'

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #26371
  • #25779

Powered by Codex Action

tutadeploy · 1 month ago

Related but not exact duplicates: #26371, #25779

Thanks for the duplicate suggestions.

I reviewed the suggested related issues:

  • #26371 appears related because it also involves excessive Codex usage while inspecting local session stores / rollout files.
  • #25779 also seems related at a broader level because it describes unbounded session/turn state and context bloat in Codex Desktop.

However, I don’t think this issue is an exact duplicate.

This report isolates a more specific mechanism:

  1. Codex autonomously investigated token usage.
  2. It executed sed over local ~/.codex/sessions/**/rollout-*.jsonl files.
  3. It later executed a broad config search:

rg ... ~/.codex -g 'config*' -g '*.json*'

  1. The *.json* glob matched .jsonl transcript files.
  2. Large Codex session transcripts were returned as tool output.
  3. That tool output was injected back into the active conversation context.
  4. Token usage then grew rapidly.

So this issue may be related to #26371 and #25779, but it provides a concrete, command-level self-log-ingestion reproduction path and sanitized evidence.

I’m happy for maintainers to link this as related, but I’d prefer to keep it open unless the team confirms this exact self-session-ingestion path is already tracked elsewhere.

tutadeploy · 1 month ago

This issue appears related to #27142, but this report provides a more specific reproduction path: Codex autonomously read/searched its own ~/.codex session JSONL logs via sed/rg, and the resulting tool outputs were injected back into the active context, causing runaway token growth.

sriinnu · 1 month ago

this is a very irritating issue which is just eating up the hdd space.

Necmttn · 29 days ago

The safest diagnostic path here is a structured summary, not raw transcript reads.

For ~/.codex/sessions/**, ~/.codex/archived_sessions/**, and rollout-*.jsonl, I would default broad rg/sed output to blocked or redacted unless the user explicitly asks for a bounded excerpt.

A built-in token-usage diagnostic could extract only fields like:

  • event counts by type
  • token_count totals and per-turn deltas
  • function call command names
  • function call output original-token estimates
  • file sizes and line counts

That answers the usage question without injecting prior prompts, tool outputs, or whole rollout records back into the active session.

---

_Generated with ax._

czc6666 · 6 days ago

I built a small local-only prototype around the safer metadata-only diagnostic suggested in this issue:

https://czc6666.github.io/repometer-lite/

It accepts a native Codex CLI rollout-*.jsonl in the browser and extracts only:

  • uncached input, cached input, and output token buckets
  • model name
  • tool-call names and counts

For Codex rollouts it deliberately discards prompts, assistant replies, function arguments, command output, code, paths, and other free text. The file never leaves the browser.

A receipt from one personal session produced 21,992 uncached input, 53,120 cached input, 569 output, and 6 tool calls. I also corrected for Codex's input_tokens including cached input, so the two buckets are not double-counted.

Current limitation: this first version does not yet reconstruct the per-turn growth timeline or detect self-log ingestion automatically, and it does not claim to explain ChatGPT subscription quota depletion. I am validating whether the safe token/tool breakdown itself is useful before adding those diagnostics.

If anyone affected by this issue tries it with a personal, non-sensitive rollout, the most useful feedback would be: did it parse successfully, and which one missing signal would have made the receipt useful for this investigation?

Source: https://github.com/czc6666/repometer-lite

czc6666 · 6 days ago

Update: I added the two diagnostics most specific to this report instead of only showing aggregate token buckets:

  • detects tool calls that target ~/.codex/sessions, ~/.codex/archived_sessions, or rollout-*.jsonl
  • detects sharp per-turn input growth and reports the largest jump plus peak input

The command text and tool output are inspected locally for the signal and then discarded; they are not rendered or sent remotely. A browser test with a synthetic self-log read correctly reported one self-log access and a 78,000-token input jump without exposing the rollout name or transcript content.

Same local page: https://czc6666.github.io/repometer-lite/