Opening the ChatGPT desktop app silently consumes the Codex weekly limit (fixed 6% per background suggestion run; reproduced under controlled conditions)

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

• #36733
• #36848
• #36481

Powered by Codex Action

Live reproduction #3, minutes after filing this issue.

After quitting the app (drain stopped, 91% held for >1h), I relaunched the app at ~22:5x KST and left it idle — no prompts submitted.

• 23:10 KST: used_percent 9 → 10 (remaining 91% → 90%), app idle in background.

That is now three consecutive on/off cycles with the same result: launch → drain begins, quit → drain stops immediately, relaunch → drain resumes. I am continuing 15-minute polling with the app left open to see whether this run also settles at exactly −6% (i.e. 85%), consistent with the fixed-cost quantization described above. Will post the completed curve here.

Re the potential duplicates flagged by the bot (#36733, #36848, #36481): these describe the same symptom family — the desktop app consuming weekly quota while idle — but this issue is not a plain duplicate. What it adds:

• A controlled experiment with a negative control: 103h 47m with all clients dead → 0% consumed; ~41h with valid credentials but app quit → 0% consumed. The drain occurs only while the app is running, verified over three consecutive launch/quit cycles (launch → drain begins, quit → stops immediately, relaunch → resumes).
• A fixed-cost measurement: exactly −6% per background run regardless of workload (n=3 including two 2026-07-22 measurements where 52 model calls and 4 model calls each cost the identical 6%), suggesting the weekly window is quantized (~16–17 slots).
• Confirmation that the traffic is app-direct to the backend (no local CLI sessions, no cloud tasks, nothing through a local proxy ledger), which is why affected users find no local evidence — consistent with what #36481 and #36848 report as "no local requests".

Happy to have a maintainer consolidate these under one tracking issue; until then I'll keep this open as the controlled-reproduction dataset. I can provide the full minute-resolution TSV log on request.

The controlled launch/quit experiments make one missing product primitive very visible: every billable background execution needs a durable causal ledger entry that can be joined to the usage deduction.

Right now the user can observe:

usage window changed by 6%
app was open
notifications appeared

but there is no authoritative record saying which logical background operation consumed that quota.

I would give every app-initiated model/background run a stable operation identity and attribution envelope:

operation_id
kind = ambient_suggestion | pending_turn | title | user_turn | ...
trigger = app_launch | thread_open | explicit_user_action | scheduler
thread_id/project_id if applicable
started_at / completed_at
request_count / token usage if available
usage_ledger_entry_id
user_initiated = true|false

Then the usage surface can reconcile server-side deductions against operations instead of showing only an aggregate rolling percentage. For background work, the app can also enforce policy before dispatch: user_initiated=false + billable => require opt-in / declared budget / visible notification, depending on product intent.

The fixed 6% observation is especially important to preserve in diagnostics without assuming the billing mechanism: if quota is slot/quantum-based rather than token-linear, the ledger should record the server's actual charged unit alongside measured model work rather than attempting to infer cost from token counts.

A regression/control test could mirror the reporter's experiment:

app closed 24h             => no background operation ids, no attributed deductions
app launched idle          => any deduction must reference ≥1 background operation
quit app                   => no new background operation starts
same operation retried     => ledger shows retry lineage, not an unexplained second charge

The invariant is: if product-owned background activity can consume a user limit, the causal execution record must be observable and attributable to that limit change.

Root cause identified: Chronicle (desktop screen-memory summaries).

After the drain reproduced, I found ~/.codex/memories/extensions/chronicle/resources/ full of *-10min-memory-summary.md files. Their counts line up with every incident on this account:

| Date | Chronicle 10-min summaries generated | Incident |
|---|---|---|
| 2026-07-21 | 93 | original burn (71% → 0%) |
| 2026-07-22 | 14 | −6% steps after reset |
| 2026-07-29 | 130 | 100% → 0% in ~11h |
| 2026-08-01 | 5 | "3% in 36 minutes" |
| 2026-08-07 | 10 | this issue's controlled reproduction (97% → 89%) |

On 08-07 the correlation is minute-for-minute: summary files written at 21:15 / 21:26 / 21:37 KST match the ~1%-per-15-min drain readings, and after relaunch, files at 23:06 / 23:17 match the 91→90→89 readings exactly. At roughly 1 summary ≈ 1% of the weekly window, 130 summaries on 07-29 fully accounts for the total burn.

So the mechanism is: with chronicle = true (Settings > Personalization), the desktop app periodically generates screen-context memory summaries via billed model calls while the app is open — no user prompts involved. This matches #36733's "background memory jobs drain plan quota while idle" report.

One open question: the memories.min_rate_limit_remaining_percent startup guard has existed since April (#19990, codex-rs/memories/write/src/guard.rs), yet 07-29 burned to 0%. Either the Chronicle summary path doesn't go through that guard, or generation simply tracks user screen activity (on 08-07, file timestamps coincide with the moments I was actually interacting with the app). Maintainers can tell from the app-side code.

Mitigation that worked here: chronicle = false (and memories = false) in config.toml / Settings > Personalization. Full minute-resolution TSV available on request.

Corroborating this on ChatGPT Pro (the report above is Plus), same OS build (Darwin 25.5.0). Independent measurement, adding to the "background activity burns the weekly window with no user prompt" pattern.

Matching your findings

• On 2026-08-05 my weekly window went 0% → 100% while my local rollout logs for that day account for only 17.3M tokens. Consumption is not proportional to local work, which lines up with your quantized-slot model.
• My ~/.codex/ambient-suggestions/ contains runs generated at 08:21 and 11:04 on 2026-08-10 that I never requested.
• I confirm your point that local logs cannot show this. I spent a full day parsing ~/.codex/sessions/**/*.jsonl and the numbers never reconciled — the implied token cost per 1% swung between 0.1M and 22M depending on the day. Your slot model explains that; token accounting cannot.
• Support gave me the same treatment (case opened 2026-08-10): two automated replies about data export, conversation deletion, and account deletion, none of which relate to a billing question.

Additional data from the Chronicle side (not yet in this thread)

Chronicle appears to be a second, separate drain on the same window:

1. Interval. Docs state 10-minute summaries. I measured 1,436 summaries between 2026-08-03 and 08-10 — an average of roughly one every 7 minutes.
2. Retention. Docs state recordings are deleted after 6 hours. A full week of summaries remained on disk, plus 1,050 summaries from May 2026 that had been synced to iCloud through ~/.codex/memories_extensions. 1,680 screen-capture JPEGs (434 MB) were also present.
3. Disabling does not stop the running process. After setting features.chronicle = false, the already-running codex_chronicle process (uptime 6h13m) kept going and rewrote summary files I had just deleted. I had to kill it manually. Only after killing it and restarting the app did it stay down — so the flag appears to be read at launch and ignored at runtime. A user who disables Chronicle to stop the drain keeps paying until they happen to check pgrep.
4. A memory-consolidation batch processed 159 sessions in one run, taking 2 percentage points of the weekly window at once.

Environment
ChatGPT.app 26.803.41515 / codex-cli 0.147.0 / macOS 26.5.2 (arm64) / Plan: Pro

Supporting your requested fixes

A user-accessible usage ledger is the core issue. Without it, neither of us could attribute our own consumption, and both of us had to run multi-day investigations to recover something the product already knows.

@rikyunezumi61-takanoha Thank you — I can corroborate parts of your Chronicle findings from the original (Plus) account:

• Old-location leftovers confirmed here too. ~/.codex/memories_extensions/chronicle/ on this Mac still holds 705 ten-minute summaries from April–May 2026 (6.9 MB), months past any documented retention. So Chronicle had been running on this machine since at least late April.
• This also explains why the drain went unnoticed for months. This account was on Pro until 2026-07-15 and switched to Plus then — the same background cost that is invisible inside a Pro-sized window becomes several percent per run on Plus. The incident timeline on this account starts exactly after the plan change.
• One behavioral difference from your report: on ChatGPT.app with Codex Framework 151.0.7922.71, after setting chronicle = false (+memories = false) in config.toml without restarting the app, I measured 8 hours with zero window consumption and zero new summary files, and no codex_chronicle process is present now. So the runtime-flag-ignored behavior you observed may be build-dependent — worth including your app build when maintainers triage. Either way your advice stands: after disabling, verify with pgrep -fl chronicle and check ~/.codex/memories/extensions/chronicle/resources/ for fresh files.

Agreed that the root ask remains a user-accessible usage ledger — three independent multi-day investigations (yours, mine, and the earlier duplicates) all exist only because the product doesn't expose what it already knows.

@Tygb99 Thank you — both for the corroboration and especially for the build-dependent correction. That kind of counter-observation is exactly what keeps a thread like this credible.

Following your advice, I have reported my exact build (ChatGPT.app 26.803.41515, build 6321 / codex-cli 0.147.0) to OpenAI support with the runtime-flag observation scoped to my environment only, noting your 151.0.7922.71 result as evidence it may not be universal.

One additional data point on the "local logs cannot show this" front: my local log store (~/.codex/logs_2.sqlite, 147,055 rows covering 2026-08-02 onward) contains zero rows whose target, module_path, or file fields reference chronicle. So even while the process was demonstrably running and rewriting files, it emitted no log lines locally. Whatever ledger exists is server-side only — which is your root ask, and I agree it remains the core issue.

Your plan-change observation (invisible inside a Pro-sized window, several percent per run on Plus) also matches my timeline from the other side: I was on Pro the whole time and only caught it by reconciling rate-limit records manually.

I observed a related case on a ChatGPT Pro account in the EU, with one important cross-device detail.

Timeline

• My weekly Codex meter showed 5% remaining at approximately 19:21.
• I submitted no further prompts and had no Codex tasks, CLI sessions, IDE integrations, or scheduled automations running.
• ChatGPT Desktop remained open in the background.
• The Mac then entered sleep automatically and remained asleep overnight.
• At approximately 07:41 the following morning, I checked the usage meter from the ChatGPT iOS app before waking or interacting with the Mac.
• The weekly meter was already at 0% remaining.
• While it showed 0%, the iOS app would not allow me to add attachments.
• The weekly allowance reset at approximately 08:01, at its previously scheduled reset time.

The fact that the server-side meter was already at 0% on iOS before the Mac was awakened rules out the desktop app's wake/resume event as the trigger.

It does not distinguish between:

1. background activity initiated before the Mac entered sleep,
2. activity during a macOS background wake,
3. server-side pending or ambient work associated with the open desktop app,
4. delayed reconciliation of usage generated earlier.

However, there was no explicit user-initiated Codex activity between the 5% and 0% observations.

Earlier that evening I had separately observed the meter move from 10% remaining to 6% remaining while generating images in an ordinary ChatGPT browser conversation, with no concurrent local Codex requests. Current OpenAI documentation says built-in image generation can count toward general Codex usage limits, so I am treating that measured four-point decrease as a separate event, not necessarily the same bug.

The unexplained event is specifically the final 5% disappearing server-side while the Mac remained asleep, with the result independently visible from iOS before the desktop machine was awakened.

This may still be compatible with the pending-turn or ambient-suggestion behavior described in this issue, but it was not triggered by waking or reopening the desktop client. A user-accessible usage ledger would be needed to identify the actual request or accounting event.

Additional macOS Plus reproduction: hidden ambient_suggestions consume quota

I can independently reproduce this on macOS with a ChatGPT Plus subscription.

I initially had no visible Codex task running and no visible scheduled task, but my remaining Codex allowance dropped from 41% → 39% → 37% within a few hours while Codex Desktop was open.

I then inspected the local Codex operational database at:

~/.codex/logs_2.sqlite

The logs confirm hidden model turns that are not shown as normal foreground tasks.

At 2026-08-20 15:35:49 +08:00, Codex created a synthetic TurnInput beginning with:

Generate 0 to 3 hyperpersonalized suggestions for what this user can do with Codex in this local project...

At 15:35:54, this produced a real sampling request using:

model=gpt-5.6-terra
reasoning_effort=medium

A second background ambient-suggestions turn occurred at 16:07:46, followed by another real gpt-5.6-terra / medium sampling request at 16:07:51.

The logs also contain multiple additional hidden helper turns using gpt-5.6-luna / low to generate one-line activity updates beneath Codex tasks.

Separately, I found one self-deleting heartbeat automation that ran at 15:22:11 using gpt-5.6-terra / xhigh. Because that automation deleted itself after execution, it was no longer visible in the task list afterward. However, the later ambient-suggestions calls occurred independently and demonstrate that quota-consuming hidden background model requests continued outside the visible task list.

After I fully quit Codex Desktop, both ~/.codex/logs_2.sqlite and its WAL stopped being written at approximately 17:56:18.

This appears to be the same class of issue described here: simply keeping the Desktop app open can trigger non-user-initiated model generations that consume a paid Plus allowance.

Please:

1. Confirm whether ambient_suggestions and activity-summary generations are intentionally charged against the user's Codex allowance.
2. Provide a supported and clearly documented global opt-out for all background model generations.
3. Do not charge user quota for model calls that were not explicitly initiated or opted into by the user.
4. Provide a user-visible usage ledger showing which task/background feature consumed quota and when.
5. Review whether quota lost to these unsolicited background generations can be restored.

I can provide sanitized SQLite excerpts, timestamps, thread IDs, and screenshots if useful.

In /.codex/config.toml, setting ambient-suggestions-enabled = false might help. It seems usage has been stable since making this change so far (will report again if doesn't work as expected)

Guys OpenAI isn't going to look at this themselves, we need to spam Tibo's feed

lets do it

Guys OpenAI isn't going to look at this themselves, we need to spam Tibo's feed

https://x.com/yong_____jjang/status/2091685199067365741

Additional default-state and configuration evidence

Environment: macOS, ChatGPT desktop 26.818.41509 build 6962, codex-cli 0.149.0.

I do not recall ever seeing or opting into a suggested prompt. However, inspection of this installed app build shows that ambient-suggestions-enabled defaults to true.

The key was absent from ~/.codex/.codex-global-state.json, meaning there was no recorded user opt-in or opt-out and the app used its enabled default.

I also found four older files under ~/.codex/ambient-suggestions/, despite never knowingly using the feature.

Persistent override

The precise configuration override is:

# ~/.codex/config.toml

[desktop]
ambient-suggestions-enabled = false

Users who want to stop background memory generation while retaining access to existing memories can use:

[memories]
generate_memories = false
use_memories = true

[features]
memories = true
chronicle = false

I verified that:

• The configuration parses and persists.
• Chronicle reports as disabled.
• Memories remains enabled for reading existing memories.
• No Chronicle or Computer History process or storage directory was active on this machine.

Restarting the desktop app is advisable because runtime handling appears to vary between builds.
I have not yet completed a controlled before-and-after quota observation. This evidence confirms the invisible enabled default and the exact opt-out syntax; it does not independently establish the amount of quota consumed.

Additional macOS Plus reproduction with precise per-call log evidence

Corroborating this issue with a fully time-boxed reproduction and per-call log evidence.

Environment:

• macOS 26.5.1 (Darwin 25.5.0, arm64)
• ChatGPT.app version 26.820.60940 (build 7119)
• Subscription: ChatGPT Plus

Incident window: 2026-08-26 20:30–23:46 (UTC+8) / 2026-08-26 12:30–15:46 UTC
Observed impact: ~40% of weekly Codex usage consumed with zero chat messages sent during the window.

Root cause confirmed via local desktop logs (~/Library/Logs/com.openai.codex/2026/08/26/codex-desktop-*-t0-i1-063332-0.log): Chronicle was actively running throughout, making real billed model calls (gpt-5.5, reasoning_effort=medium) roughly every 2 minutes:

15:30:48Z  starting codex exec summary session  model=gpt-5.5  reasoning_effort=medium
15:32:29Z  completed summary session → .../chronicle/resources/2026-08-26T09-40-00-...-10min-memory-summary.md
15:33:33Z  starting codex exec summary session
15:34:58Z  starting codex exec summary session
15:36:58Z  starting codex exec summary session
15:38:58Z  starting codex exec summary session
15:40:58Z  starting codex exec summary session
15:42:58Z  starting codex exec summary session
15:45:08Z  starting codex exec summary session
(app-server connection dropped at 15:46:25Z, ending the log)

11 summary-generation calls were started in this window; only 4 completed before the connection dropped (the other 7 were in-flight when the app disconnected). Across the full day, 32 such 10-minute summary files were written to ~/codex/memories/extensions/chronicle/resources/, with bucket timestamps showing this was a backlog catch-up batch spanning screen-recording buckets from Aug 10–13 and Aug 25 — not routine incremental usage from that evening alone.

Confirming the "invisible enabled default" point from @NellInc's comment above: my ~/.codex/config.toml never contained the string chronicle at all (checked via grep against the full file), so it ran on whatever the shipped default is. I had already set ambient-suggestions-enabled = false under [desktop] weeks earlier, which had zero effect on this drain since Chronicle is a separate flag under [features].

Mitigation applied: added

[features]
chronicle = false

and fully quit/relaunched the app (not just closed the window).

Given this is now corroborated across at least 4-5 independent accounts/platforms with matching mechanism (fixed background 10-min summary cadence, real model calls, invisible-by-default), it would help a lot to get an explicit maintainer acknowledgment and a target for making chronicle opt-in by default, plus guidance on requesting quota restoration for windows like this one.

Cross-linking this controlled passive/background-consumption reproduction to #41220, a meta tracker for abnormal Codex usage/quota depletion and usage-accounting inconsistencies. This issue is especially useful because it isolates client state: >103 hours with clients closed showed no drain, launching the desktop app/background activity produced the observed fixed deduction, and quitting stopped it. #41220 is intentionally a symptom-family tracker rather than a claim that every linked report shares one root cause.