Codex Chronicle silently drains subscription quota 24/7 and triggers auth token invalidation

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

• #26808

Powered by Codex Action

I can reproduce a closely related variant of this on Codex Desktop for macOS.

Environment observed:

• Codex Desktop on macOS
• App resources version observed in process paths: 149.0.7827.197
• Date observed: 2026-06-29, Asia/Shanghai

What I observed:

• The user believed Chronicle had been disabled and raw screen recording cache had previously been cleared.
• After launching Codex Desktop again, Codex started:

/Applications/Codex.app/Contents/Resources/codex_chronicle
codex exec --json ... --model gpt-5.5 ... --config model_provider="openai-memgen" ... --cd $TMPDIR/chronicle/screen_recording -

• In the latest 5-hour window, the local Chronicle resources directory had 84 newly modified 10min-memory-summary.md files, including 36 in the 20:00 hour.
• This was not a user-created automation.

Additional evidence that may help isolate the cause:

• ~/.codex/config.toml still contained:

[features]
chronicle = true

• The persisted app/global state also had:

{
  "chronicle-consent-accepted": true,
  "chronicle-setup-completion-pending": false
}

• Manually setting chronicle-consent-accepted=false was not sufficient while the app was running; it was later written back to true.
• The effective workaround was to set:

[features]
chronicle = false

and then stop codex_chronicle, clear $TMPDIR/chronicle/screen_recording, and revoke macOS Screen Recording permission for com.openai.codex.

Why this seems like a product bug / transparency issue:

• A stale or hidden local config value can cause Codex Desktop to restart Chronicle and model-backed openai-memgen background jobs even when the user believes the feature was disabled.
• The quota impact is not visible as a user-initiated task.
• Disabling Chronicle should be authoritative across config, persisted consent state, background workers, and macOS permission state, or Codex should ask for fresh explicit confirmation before restarting it.

Same pattern here on Pro, ChatGPT.app 26.803.41515 / codex-cli 0.147.0 / macOS 26.5.2 (arm64). Also three weekly-window exhaustions (2026-07-24, 07-26, 08-05) before I found the cause.

Adding three measurements that I don't think are in this thread yet.

1. features.chronicle = false does not stop the already-running process

Setting the flag in ~/.codex/config.toml had no effect on the live codex_chronicle process (uptime 6h13m at the time). It kept running and rewrote summary files I had just deleted — 16 of them, several minutes after deletion. I had to kill the PID manually. Only after killing it and restarting the app did it stay down.

So the flag appears to be evaluated at launch and ignored at runtime. Practical consequence: a user who finds this thread, sets the flag, and assumes the drain has stopped will keep paying until they happen to run pgrep -x codex_chronicle.

2. Summary interval is ~7 minutes, not the documented 10

1,436 summaries were generated between 2026-08-03 and 08-10 in ~/.codex/memories/extensions/chronicle/resources/ — an average of one every ~7 minutes.

3. Summaries are not covered by the 6-hour deletion policy

The docs state recordings are deleted after 6 hours. That appears to apply to the raw captures only. On my machine:

• A full week of summaries remained on disk.
• 1,050 additional summaries from May 2026 were still present, having been synced to iCloud via ~/.codex/memories_extensions. That is three months of retained screen-derived content.
• 1,680 screen-capture JPEGs (434 MB) were present under $TMPDIR/chronicle/screen_recording/.

4. Related: memory consolidation is a second spike

Separately from the 7-minute cadence, a memory-consolidation batch processed 159 sessions in a single run and took 2 percentage points of the weekly window at once.

On visibility

Echoing the original report: there is no Chronicle-specific consumption view. It took me a full day of parsing ~/.codex/sessions/**/*.jsonl to identify this, and the numbers still didn't reconcile — see #37445, where the reporter shows the weekly window behaves as quantized slots rather than token-proportional accounting.

One more note for anyone cleaning up after this: the generated MEMORY.md retained business content in plaintext, and it persisted in that directory's git baseline commit after I deleted the file. Removing the file is not sufficient.