Codex quota was exhausted again during a short working session.

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

• #28687
• #28694
• #28498
• #27608

Powered by Codex Action

facing this same issue +1

<img width="1029" height="1148" alt="Image" src="https://github.com/user-attachments/assets/157d55c3-1ad7-4f0b-9768-0f1a3695655e" />

Мониторинг 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:

• I did not use Codex at all before launching it today.
• I simply opened the application.
• Immediately after launch I was presented with:

“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:

• remaining quota decreases while Codex is idle;
• remaining quota decreases even when I am not sending prompts;
• both the 5-hour quota and the 7-day quota decrease over time;
• the reduction continues while the application is simply open;
• in some cases the reduction continues even after periods without any interaction.

This has been reproduced multiple times.

⸻

Today’s reproduction

Today I intentionally performed another clean test.

Test conditions

• Codex was not used before the test.
• No prompts were submitted.
• No projects were opened.
• No local tasks were started manually.
• No repositories were indexed manually.

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:

• process lists;
• CPU usage;
• memory usage;
• running ChatGPT/Codex processes;
• timestamps over many hours.

The monitoring log shows:

• ChatGPT and ChatGPTHelper processes were present;
• no sustained CPU activity corresponding to model inference;
• no obvious local workload capable of consuming the amount of quota observed;
• no repeated foreground requests were executed by me.

The complete monitoring log is attached.

⸻

Additional investigation already performed

Before opening this report I attempted to eliminate common local causes.

Environment

• macOS
• Latest ChatGPT desktop application
• Codex

I verified

• no duplicate ChatGPT processes;
• no orphan Codex processes;
• no abnormal startup items;
• no login items repeatedly launching Codex;
• no obvious extensions responsible for repeated execution;
• no obvious background jobs started by me.

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:

• quota decreasing while idle;
• Codex becoming blocked without user interaction;
• unexplained background quota consumption.

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:

• foreground_prompt
• background_task
• project_indexing
• retry
• resume
• memory_writer
• server_adjustment
• session ID
• request ID
• model
• timestamp

Without this information it is impossible to determine whether quota was consumed by:

• foreground requests,
• background processing,
• delayed accounting,
• or an accounting bug.

⸻

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:

1. Which events were recorded as quota-consuming.
2. Whether any background operations consumed message quota.
3. Whether project indexing, synchronization or reconciliation consume the same quota.
4. Whether this behavior is expected.
5. If expected, how users can distinguish foreground usage from background quota consumption.

If this is not expected behavior, I believe there may be an issue in the quota accounting system.

⸻

Attachments

I am attaching:

• screenshots showing quota decreasing over time;
• screenshots showing the application opening directly into the “quota exhausted” state;
• continuous monitoring logs covering many hours of idle operation;
• previous screenshots documenting the gradual quota reduction.

⸻

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:

• screenshots;
• long-term process monitoring;
• terminal logs;
• repository isolation tests;
• local environment investigation;
• reproduction attempts.

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:

• what exactly consumed my quota;
• whether foreground prompts, background tasks, retries, indexing, session recovery, or server-side reconciliation are counted;
• why quota decreases while no visible task is running;
• why quota can already be exhausted before my first interaction after launching Codex.

I have attempted to eliminate every reasonable local explanation.

I investigated:

• Git repositories;
• workspace size;
• local processes;
• CPU usage;
• local Codex task databases;
• application caches.

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:

• timestamp;
• event type;
• quota delta;
• session/thread ID;
• request ID;
• model;
• source of consumption.

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.

Вот так будет значительно сильнее и честнее.

⸻

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.

1. Check for background Codex processes

ps -axo pid,ppid,%cpu,%mem,time,command | \
grep -Ei "codex exec|autowake|cua_node|SkyComputerUseService" | grep -v grep

1. Stop all detected background processes

pkill -f "codex exec"
pkill -f "autowake"
pkill -f "cua_node"
pkill -f "SkyComputerUseService"

1. Check LaunchAgents

launchctl list | grep -Ei "codex|autowake|enir"

1. Remove any unwanted LaunchAgents

launchctl remove <agent_name>

1. Find LaunchAgent plist files

find ~/Library/LaunchAgents /Library/LaunchAgents /Library/LaunchDaemons \
-iname "codex" -o -iname "enir" -o -iname "autowake" 2>/dev/null

1. Disable the local autowake directory (if present)

mv ~/.codex/autowake ~/.codex/autowake_DISABLED_$(date +%Y%m%d_%H%M%S)

1. Verify that only the normal Codex application remains

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.