Codex App consumes rate limit on startup without any user action #22073

Activity

1. RonitGandotra05

   added

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

   on May 11, 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

   on May 11, 2026
3. github-actions commented on May 11, 2026

   

   github-actionsbot

   on May 11, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Codex Desktop open → 5-hour usage decreases after reset despite no active task, no CLI, and no credit-history event. #21966

   Powered by Codex Action
4. show940125 commented on May 11, 2026

   

   show940125

   on May 11, 2026

   Last edited by show940125

   More actions

   I am seeing the same class of issue on Windows, with an additional pattern: the quota appears to decrease not only on startup/restart, but also when opening existing sections/sessions, before sending any prompt.

   Environment:

   • Codex App: 26.506.31421 (2620)
   • Embedded codex.exe: 0.130.0-alpha.5
   • Platform: Windows 11 Home, 10.0.26200, x64
   • Subscription: ChatGPT Plus plan usage windows shown in the Codex app UI

   Observed today (2026-05-11, Asia):

   • This was my first Codex message of the day.
   • I expected the 5-hour window to be at 100% remaining and the weekly window to be around 20% remaining.
   • Immediately after opening Codex, before doing any work, the 5-hour remaining value was already 99% instead of 100%.
   • After opening a section/session, the 5-hour remaining value dropped from 99% to 97%, and the weekly remaining value dropped from 20% to 19%.
   • After fully closing and reopening Codex, the 5-hour remaining value continued to drop by another ~1-2% without submitting any prompt.
   • Opening other sections/sessions appeared to trigger additional ~1-2% decreases.
   • Overall, before meaningful user work, the 5-hour remaining value had decreased by roughly 10%+ and the weekly remaining value by about 2%.

   Local checks I ran while investigating:

   • No common dev-server listener was present on ports.
   • Codex-spawned local MCP/helper Python processes were present, but a short CPU delta sample showed them at 0.00 CPU seconds; node_repl was also effectively idle.
   • The only active Codex processes showed light app activity, not a heavy background job.

   This looks very similar to #21966 as well: either hidden/background app-server work is consuming shared usage, or the UI/backend is reconciling/attributing usage incorrectly. The important part from the user perspective is that the 5-hour and weekly percentages changed before any prompt, command, edit, or explicit task was submitted.

   Expected behavior:

   • Launching/relaunching Codex and opening existing sections/sessions should not consume 5-hour or weekly usage by itself.
   • If startup/session hydration/indexing/memory/sync does consume quota, the UI should attribute it explicitly so users can see what happened.
5. pourdamghani commented on May 13, 2026

   

   pourdamghani

   on May 13, 2026

   More actions

   Same issue on Mac, just after opening the Codex after a day. If there are some background processes, there should be an option to toggle them off...
6. udrewicz commented on Jul 23, 2026

   

   udrewicz

   on Jul 23, 2026

   More actions

   This issue is a few months old, but I started experiencing the same problem after the latest Codex update.

   In my case, simply opening existing conversations appears to consume the weekly limit. I did not send any messages, start any tasks, run any commands, or edit any files.

   I opened around 10 existing conversations just to check their contents, and my weekly limit dropped by 1%.

   A few hours later, I repeated the test:

   Checked the weekly limit.
   Completely closed and reopened Codex.
   Opened the existing conversations again without sending anything.
   The weekly limit dropped by another 1%.

   Since the tests were performed several hours apart and the same result occurred twice, this does not look like delayed usage reporting or a simple display refresh.

   This started only after the latest update. It looks like opening/resuming existing conversations may now trigger some background model usage or incorrect rate-limit accounting.

   Platform: Windows
   Codex version: [Version 26.715.72359]

   Please let me know which logs would be useful for diagnosing this.
7. BLACKIELF commented on Sep 17, 2026

   

   BLACKIELF

   on Sep 17, 2026

   Last edited by BLACKIELF

   More actions

   Adding a datapoint with precise timings from macOS (Darwin 25.6.0, arm64), Codex Desktop 152.0.7977.83 with embedded codex CLI 0.154.0-alpha.6.2, ChatGPT Plus.

   Setup caveat for transparency: this machine runs a multi-account setup (one CODEX_HOME profile per account; my own open-source account manager, AgentHub-AiGoodBro, swaps the shared ~/.codex/auth.json). The currently logged-in account is the one whose limits get consumed. That manager also has an optional "warm-up" pinger, but each ping is a minimal single-turn "hi" request with empty instructions, which cannot account for the 20%+ jumps below — and consumption stopped exactly when the Codex app was quit, while the manager kept running. The burst pattern otherwise matches the reports above and the weekly-window issues (#44339, #43574) exactly.

   Timeline (local time, UTC+8; quota percentages from the same snapshot data the app displays, polled every 1–4 minutes):

   • 03:29 — switched to another account of the same plan; the Codex app relaunched at 03:32:51 (relaunch happens on account switch). A new codex app-server child spawned at 03:32:52 and re-opened the ~94 MB rollout of a previous conversation (started the night before; 2 user messages total; ~10.6M cumulative tokens, video attachments included).
   • 03:35–03:36 — 5-hour window jumped 0% → 22% with no prompt sent. No user message existed in the app at this point; the only rollout activity was session-restore bookkeeping (thread_settings_applied events).
   • 03:39–03:42 — further jumps to 56% → 89% (5-hour), while the weekly window climbed 82% → 96%. The app sat idle the whole time.
   • 03:40 — my only in-app action: sending "pause all tasks". This itself opened a new billed session (a new rollout file appeared at 03:40:39).
   • 03:43 — quit the app and killed the orphaned codex app-server processes → consumption stopped immediately (two readings 40 seconds apart: identical numbers; zero codex processes left; no new rollout files).

   Takeaways:

   1. Consumption occurred on app relaunch + restoring an existing large conversation, before any prompt — consistent with the "opening existing conversations consumes weekly limit" reports above.
   2. Every message sent in the app is itself a new billed session — even a "pause everything" request costs quota, which makes in-app mitigation self-defeating.
   3. Net damage in ~10 minutes of zero real work: 5-hour 0% → 96%, weekly 82% → 97%.

   Happy to provide sanitized rollout excerpts or the full polling log if useful.