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

Activity

1. famtastic-fritz

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Jun 12, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   rate-limitsIssues related to rate limits, quotas, and token usage reportingIssues related to rate limits, quotas, and token usage reporting

   authIssues related to authentication and accountsIssues related to authentication and accounts

   on Jun 12, 2026
3. github-actions commented on Jun 12, 2026

   

   github-actionsbot

   on Jun 12, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Chronicle memory writer should expose model and cost controls #26808

   Powered by Codex Action
4. yuhuamiss commented on Jun 29, 2026

   

   yuhuamiss

   on Jun 29, 2026

   More actions

   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.
5. rikyunezumi61-takanoha commented on Aug 10, 2026

   

   rikyunezumi61-takanoha

   on Aug 10, 2026

   More actions

   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.
6. tdonald8527-spec commented on Sep 14, 2026

   

   tdonald8527-spec

   on Sep 14, 2026 – with ChatGPT Codex Connector

   More actions

   I reproduced the same issue on macOS with a ChatGPT Plus account, and I was able to isolate Chronicle as the likely source of the unexpected quota drain.

   Observed behavior:

   • I was not actively submitting Codex or Work requests.
   • My Codex 5-hour remaining allowance dropped from about 89% to 0% over roughly 5 hours while I was idle.
   • Local audit confirmed chronicle = true, with memories = true, generate_memories = true, and use_memories = true.
   • codex_chronicle was running and was observed spawning a real background process using codex exec --model gpt-5.5 with the openai-memgen provider.
   • The child process had an established HTTPS connection and was operating on Chronicle screen-recording data to generate memory summaries.
   • Sep 12 logs showed a large number of automatic starting codex exec summary session events, including retries/failures, and multiple entries containing You've hit your usage limit.
   • Chronicle-generated 10min-memory-summary.md files were also being created continuously.

   Most importantly, after I disabled Chronicle and stopped the Chronicle process, the abnormal quota consumption stopped. I have not seen the same idle drain since.

   This makes the causal chain look like:

   Chronicle enabled -> periodic screen/OCR summarization -> background codex exec (gpt-5.5) -> subscription quota consumed while user is idle

   I think the product should make this much more visible because from the normal Codex task list it looked like there were no active tasks, yet Chronicle was still producing quota-bearing model requests in the background.

   Suggested improvements:

   1. Clearly disclose that Chronicle consumes the normal Codex subscription allowance.
   2. Show Chronicle usage separately in Analytics/Usage.
   3. Provide an obvious UI toggle to disable it.
   4. Warn users before enabling it that it can materially consume the 5-hour/weekly quota.
   5. Consider a lower-cost model/frequency or a separate background quota for Chronicle memory generation.

   I can provide sanitized local logs and Analytics screenshots if maintainers need them.