›_ Codex Issues
Codex Issues / #22073

Codex App consumes rate limit on startup without any user action

Open 💬 4 comments Opened May 11, 2026 by RonitGandotra05
💡 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)?

Version 26.506.31421 (2620)

What subscription do you have?

plus

What platform is your computer?

Darwin 25.4.0 arm64 arm(macbook m4)

What issue are you seeing?

When I reopen the Codex app after some time, usually after around 24 hours or after leaving it closed for a long period, it automatically consumes my rate limits without any user action. Around 6% to 8% of my 5-hour limit and around 1% to 2% of my weekly limit get used just by opening the app. I do not send any prompt, edit any file, run any command, or ask Codex to perform anything. The expected behavior is that rate limits should only be consumed when I actually submit a prompt or Codex performs a requested action.

What steps can reproduce the bug?

  1. Check the current Codex app 5-hour rate limit and weekly rate limit usage.
  2. Quit the Codex app completely.
  3. Leave the app closed for a long period, for example around 20-24 hours.
  4. Reopen the Codex app.
  5. Do not send any prompt, edit any file, run any command, or start any task.
  6. Check the rate limit usage again.

After reopening the app, my 5-hour rate limit increases by around 6% to 8%, and my weekly limit increases by around 1% to 2%, even though I did not perform any action.

I do not have a code snippet because this happens just by launching the Codex desktop app. I can provide screenshots showing the rate limit usage before and after reopening the app.

What is the expected behavior?

Opening or reopening the Codex app should not consume any 5-hour or weekly rate limit by itself. Rate limits should only be consumed when I submit a prompt, start a task, edit files through Codex, run a command, or explicitly ask Codex to perform an action.

Additional information

_No response_

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 3 months ago

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

  • #21966

Powered by Codex Action

show940125 · 3 months ago

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.
pourdamghani · 3 months ago

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...

udrewicz · 1 month ago

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.