Repository navigation
Unexpected weekly usage reset overwrites active Codex window and moves reset date — third occurrence #38332
Description
What version of Codex CLI is running?
codex-cli 0.147.0
What subscription do you have?
ChatGPT Plus
Which model were you using?
gpt-5.6-sol with reasoning set to High
What platform is your computer?
Ubuntu Linux
What issue are you seeing?
On 2026-08-13 at approximately 10:30 CEST, my Codex weekly usage unexpectedly returned to 100% remaining even though I did not intentionally apply or redeem any usage reset.
Immediately after the event, /status showed:
OpenAI Codex (v0.147.0)
Model: gpt-5.6-sol (reasoning high, summaries auto)
Account: ChatGPT Plus
Session: 019ffa3e-6ddf-7af0-8873-48136545ac09
Weekly limit: 100% left (resets 10:30 on 20 Aug)
This is the third time I have observed an unsolicited full usage reset.
The important problem is not that extra usage was granted. The problem is that the reset appears to replace the currently active weekly window with a new seven-day window starting at the time of the unsolicited reset. That changes the previously displayed reset schedule and makes it impossible to plan usage reliably.
I had been deliberately conserving the remaining weekly allowance based on the reset date shown by Codex. If an unsolicited reset starts a new seven-day window immediately, then conserving usage can be counterproductive: unused capacity from the active window is effectively superseded rather than preserved or added separately.
I did not intentionally trigger a banked reset before this happened.
What steps can reproduce the bug?
I do not know the server-side trigger, so I cannot reproduce it deterministically.
Observed sequence:
- Use Codex on a normal ChatGPT Plus weekly usage window.
- Have some amount of usage remaining and a future reset timestamp shown in
/status/ the usage UI. - Do not manually apply a usage reset.
- At an apparently unsolicited time, the weekly allowance returns to 100%.
- The reset timestamp moves to exactly about seven days after the unsolicited reset event.
On this occurrence, the new state was:
100% left
resets 10:30 on 20 Aug
observed at approximately 10:30 on 13 Aug 2026.
What is the expected behavior?
Unsolicited promotional, service-recovery, milestone, or account-level reset grants should not overwrite an active weekly usage window without an explicit user choice.
Preferably:
- additional resets should be banked and shown as available to redeem later;
- the active weekly reset timestamp should remain unchanged until the user chooses to apply a reset;
- if a true hard reset must occur, the UI should clearly explain what caused it and whether unused allowance from the prior window was preserved;
- the usage interface should expose a reset-event history showing the source, timestamp, previous balance/reset time, and resulting balance/reset time.
A user who deliberately conserves usage should not lose the value of that planning because an unexpected reset silently replaces the active quota period.
Additional information
This appears related to the broader reset-window predictability problems discussed in:
- Make Weekly Limit Reset Deterministic #9508 — Make Weekly Limit Reset Deterministic
- Quota windows anchor to first post-reset use, causing lost subscription time #28246 — Quota windows anchor to first post-reset use, causing lost subscription time
- Weekly usage reset date changed unexpectedly after subscribing to ChatGPT Plus #30816 — Weekly usage reset date changed unexpectedly after subscribing to ChatGPT Plus
- [Codex App/macOS] Repeated TAC false positives after Pro upgrade interrupt authorized and benign work #36471 — reports unexpected weekly usage returning to 100% as an account-state anomaly
I am happy to provide screenshots or additional local telemetry privately if useful. I have intentionally omitted my account email from this public report.
Activity
github-actions commentedon Aug 13, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
ochiai-PCKK commentedon Sep 10, 2026
I’d like to suggest a slightly different reset model that could solve this while keeping the existing quota system mostly unchanged.
Instead of restarting the 7-day window whenever a promotional/global reset happens, please consider treating it as a quota top-up.
For example:
In other words, the regular weekly reset date/time would stay fixed, while additional resets would only replenish the remaining quota.
The current behavior makes me hesitant to use Codex heavily after a reset, because using/resetting the quota can effectively move the next reset farther into the future. It creates an incentive to think about quota timing instead of simply using Codex when I need it.
A predictable fixed reset schedule would make the system much easier to plan around, while promotional resets would actually feel like bonus capacity.
This wouldn’t necessarily require increasing the long-term quota — just separating quota replenishment from reset-window scheduling.
tarco24 commentedon Sep 11, 2026
I’m seeing the same underlying problem on a ChatGPT Pro subscription. The issue is not “wanting more free usage” — it is loss of predictable capacity planning.
I deliberately budget the weekly Codex allowance around the reset date shown in the Usage UI. When a promotional/global reset replaces the active weekly window and moves the next reset date, conserving quota can actually become disadvantageous. A user who has carefully saved capacity for later in the week can have that planning superseded by an unsolicited reset, while a user who already exhausted the quota benefits fully.
That creates the wrong incentive: instead of planning work around a stable weekly allowance, users are pushed to guess whether they should burn remaining quota before a possible global reset, wait for an unannounced reset, or redeem a banked reset and restart the weekly window.
I strongly support the proposed top-up model above:
This would preserve the promotional benefit without penalizing users who deliberately conserved their included weekly capacity.
OpenAI’s current Help Center documentation also makes the scheduling consequence of full banked resets explicit: using one refreshes the 5-hour and weekly Codex windows and changes the weekly reset date. That makes separating quota replenishment from window scheduling even more important for predictable usage:
https://help.openai.com/en/articles/20001498-how-banked-codex-resets-work
GreatMor commentedon Oct 3, 2026
I am seeing the same behavior in the Codex desktop app on Windows with a ChatGPT Plus subscription.
The unexpected refill is not itself the problem; silently replacing the active weekly window and moving the next reset date makes work planning unreliable. A top-up that preserves the existing reset date, or a visible reset-event history explaining the source and effect, would avoid this disruption.
blandocs commentedon Oct 12, 2026
I'm experiencing the exact same issue, and it has already happened to me twice.
What happened
Why this is a problem
The real problem is not the free quota refresh. It's that the original reset schedule gets overwritten.
I intentionally planned to save most of my weekly quota and use it heavily near the end of the 7-day period, so I could receive a fresh quota shortly afterward.
However, these unexpected resets keep pushing back my next reset date, making it impossible to plan my usage.
For example, if I have 97% remaining and my scheduled reset is only a few days away, resetting my quota to 100% while postponing the next reset by another 7 days is actually a disadvantage, not a benefit.
Expected behavior
Environment
Could the Codex team please clarify whether this is an intentional policy or a bug?
If account-specific logs are needed, I'm happy to provide my account details privately through an official support channel.
This is particularly frustrating for paying subscribers who plan their development work around the weekly usage limits.
shjohnson-pi commentedon Oct 14, 2026
I'm seeing similar behavior with my Codex weekly usage limit:
The reset date shifted forward by almost exactly 24 hours, and my remaining allowance increased slightly despite additional Codex usage between screenshots.
I did not manually trigger a reset. This suggests an unexpected quota recalculation or reset-window adjustment. I have screenshots documenting both states.
Windows Host, Ubuntu WSL2, codex-cli v0.161.0, Business account