Repository navigation
Codex quota was exhausted again during a short working session. #28727
Description
What version of the Codex App are you using (From “About Codex” dialog)?
Version 26.611.61753
What subscription do you have?
PRO x5
What platform is your computer?
MacOS
What issue are you seeing?
Additional update: Codex quota was exhausted again during a short working session.
I am adding another observation from the same Codex session.
Session ID:
019e4f6c-c66b-7072-8678-f4370b9c5b86
Timeline:
14:14
Context: 179,518 / 258K
5-hour quota remaining: 80%
7-day quota remaining: 80%
14:19
Context: 186,991 / 258K
5-hour quota remaining: 74%
7-day quota remaining: 80%
15:06
Context: 93,534 / 258K
5-hour quota remaining: 35%
7-day quota remaining: 74%
15:20
Context: 93,534 / 258K
5-hour quota remaining: 25%
7-day quota remaining: 72%
15:43
Context: 143,431 / 258K
5-hour quota remaining: 6%
7-day quota remaining: 69%
15:58
Context: 143,431 / 258K
5-hour quota remaining: 0%
7-day quota remaining: 68%
Codex then became unavailable with the message that the Codex message limit was exhausted.
This means that within approximately 1 hour 44 minutes, the 5-hour quota dropped from 80% to 0%, and the 7-day quota dropped from 80% to 68%.
This happened during a limited number of user actions. The consumption still appears disproportionate and not transparent.
Important observation:
Between 15:43 and 15:58, the context size remained unchanged at 143,431 / 258K, but the 5-hour quota still dropped from 6% to 0%.
I also monitored local macOS process activity during the period. The system showed load, but the visible terminal output did not clearly attribute this load to Codex or ChatGPT specifically. This makes it impossible for me to verify whether the quota depletion was caused by an actual Codex task, background activity, delayed accounting, or a quota tracking issue.
Please investigate this session and provide a detailed usage breakdown showing:
- exact charged operations;
- timestamps;
- source/client;
- task or session ID;
- whether quota was consumed by user prompts, background execution, retries, indexing, tool calls, or delayed reconciliation;
- why quota continued decreasing even when context size did not change.
This is now the second time today that Codex became blocked due to 5-hour quota exhaustion under unclear circumstances.
As a paying user relying on Codex for professional work, I need transparent and auditable quota accounting.
What steps can reproduce the bug?
- Open Codex in the ChatGPT macOS application.
- Start a normal Codex work session.
- Perform a small number of ordinary tasks involving file analysis and modifications.
- Observe the quota indicators in the session status panel.
- Continue working while periodically recording:
- 5-hour quota remaining;
- 7-day quota remaining;
- session ID;
- context size.
- Observe that the 5-hour quota decreases significantly faster than expected relative to the visible amount of work performed.
- Continue until the 5-hour quota reaches zero and Codex becomes unavailable.
Observed example from my session:
Session ID:
019e4f6c-c66b-7072-8678-f4370b9c5b86
14:14
5-hour quota: 80%
7-day quota: 80%
15:58
5-hour quota: 0%
7-day quota: 68%
Codex access was blocked due to exhaustion of the 5-hour limit.
Additional observation:
During part of the session, the context size remained unchanged while the available quota continued decreasing.
I cannot provide a deterministic reproduction sequence because the issue appears related to quota accounting rather than a specific user action. However, the behavior has now occurred multiple times during normal usage.
What is the expected behavior?
No response
Additional information
No response
Activity
github-actions commentedon Jun 17, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
waleedajaz990-web commentedon Jun 21, 2026
facing this same issue +1
excessive-eng commentedon Jun 30, 2026
Мониторинг 30.06.2026.rtf
Codex quota decreases while idle and can reach zero before first interaction
Summary
I believe there is an issue with how my Codex usage quota is being accounted for.
Over multiple days I have repeatedly observed that my remaining Codex quota decreases while I am not actively using Codex.
The most recent observation is the strongest evidence so far:
“You have run out of Codex messages.”
No prompt had been submitted.
No project had been opened.
No interaction with Codex had occurred.
This means the remaining quota reached zero before the first user action of the day.
⸻
Previous observations
For several days I have documented the following behavior:
This has been reproduced multiple times.
⸻
Today’s reproduction
Today I intentionally performed another clean test.
Test conditions
I simply launched Codex.
Immediately after launch the application reported that my message quota had already been exhausted.
⸻
Monitoring performed
To rule out local causes I prepared continuous monitoring.
I collected:
The monitoring log shows:
The complete monitoring log is attached.
⸻
Additional investigation already performed
Before opening this report I attempted to eliminate common local causes.
Environment
I verified
I also inspected the local Codex and ChatGPT application data directories.
Nothing indicates continuous local execution of prompts.
⸻
Existing community reports
After creating this issue I noticed several reports describing very similar behavior, including:
This suggests the issue may not be isolated to a single installation.
⸻
What would help identify the problem
At the moment users only see a remaining percentage.
That is insufficient to determine what actually consumed quota.
A usage ledger would make this immediately diagnosable.
Ideally each quota change would include something like:
Without this information it is impossible to determine whether quota was consumed by:
⸻
Request
Could you please investigate the quota accounting for my account?
Specifically, could you inspect the internal usage ledger between my previous Codex session and my first launch today?
I would like to know:
If this is not expected behavior, I believe there may be an issue in the quota accounting system.
⸻
Attachments
I am attaching:
⸻
excessive-eng commentedon Jul 1, 2026
I would like to formally escalate this issue.
Over the past several days I have spent many hours investigating what appears to be incorrect Codex quota accounting.
I have already submitted multiple reports and attached extensive evidence, including:
Despite all of this work, I have not received any substantive response addressing the technical observations.
Instead, every new report is automatically marked as a potential duplicate, without any indication that the evidence has actually been reviewed.
At this point my concern is no longer only the quota itself.
It is the complete lack of transparency regarding how quota is consumed.
The product UI tells me:
“You have run out of Codex messages.”
However, the pricing documentation describes the plans in terms of usage, not messages.
Those are fundamentally different concepts.
As a paying customer, I currently have no way to determine:
I have attempted to eliminate every reasonable local explanation.
I investigated:
Nothing explains the observed quota behaviour.
I am not asking for speculation.
I am asking for transparency.
Please review my attached evidence and provide a technical explanation based on the internal usage records for my account.
If Codex usage is based on something other than foreground user messages, then the product should expose that information.
At minimum, users need access to an audit trail (charge ledger) showing:
Without this information it is impossible to verify whether quota was consumed by my own actions or by background operations.
A professional paid product should provide users with sufficient information to understand why their purchased quota has been exhausted.
excessive-eng commentedon Jul 2, 2026
Вот так будет значительно сильнее и честнее.
⸻
After further investigation, I cannot conclusively determine whether the background automation was responsible for my quota consumption.
Unfortunately, I had to upgrade to a higher Codex plan before I could complete a proper long-term comparison of quota usage during periods of complete inactivity. As a result, I lost the opportunity to accurately measure whether the quota was decreasing without any user interaction.
However, during my investigation I discovered several local background LaunchAgents that were automatically starting Codex-related processes (codex exec, autowake, cua_node, SkyComputerUseService). After disabling these background jobs, only the normal Codex desktop application remained running.
For other users who suspect unexpected background activity, I recommend checking their system with the following commands.
ps -axo pid,ppid,%cpu,%mem,time,command |
grep -Ei "codex exec|autowake|cua_node|SkyComputerUseService" | grep -v grep
pkill -f "codex exec"
pkill -f "autowake"
pkill -f "cua_node"
pkill -f "SkyComputerUseService"
launchctl list | grep -Ei "codex|autowake|enir"
launchctl remove <agent_name>
find ~/Library/LaunchAgents /Library/LaunchAgents /Library/LaunchDaemons
-iname "codex" -o -iname "enir" -o -iname "autowake" 2>/dev/null
mv ~/.codex/autowake ~/.codex/autowake_DISABLED_$(date +%Y%m%d_%H%M%S)
ps -axo pid,command |
grep -Ei "codex exec|autowake|cua_node|SkyComputerUseService" | grep -v grep
I hope these steps help other users troubleshoot unexpected background Codex activity while investigating unusual quota consumption.