Automatically run automation after rate limit window allows continued usage
Resolved 💬 6 comments Opened Feb 22, 2026 by iandanforth Closed Apr 3, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor)
responded on this thread — see the highlighted reply below.
What version of the Codex App are you using (From “About Codex” dialog)?
26.217.1959 (669)
What subscription do you have?
Plus
What platform is your computer?
Darwin 24.1.0 arm64 arm
What issue are you seeing?
Automations start and then spin despite being out of Codex messages. This can lead to dozens of Automation threads open and running.
I haven't checked this but it might be that if I left them in this running but blocked state they would immediately consume messages when the limit resets (despite being stale and useless at that point).
What steps can reproduce the bug?
Create an automation that burns through your messages limit
Wait for the automation to start again.
What is the expected behavior?
The automation checks for available messages before starting and reports an error if none are available but does not start a spinning thread.
Additional information
_No response_
6 Comments
When you say "out of codex messages", do you mean that you've reached your usage limit?
The app (and harness) have no way of knowing whether you've reached your usage limit until a prompt is sent to the service.
As a clarification, usage isn't based on the number of messages you send; it's based on the number of tokens consumed (input, output and reasoning).
@etraut-openai Thank you for your response. The app displays the following
<img width="765" height="95" alt="Image" src="https://github.com/user-attachments/assets/a4a6701a-5b90-4675-92c7-e0ad63c76159" />
that's where the messages terminology comes from.
If the app has hit this state the expected behavior would be for automations to either 1. Wait until the displayed reset time has passed or 2. Check before running that messages / tokens / credits are available to the logged in account.
Ah thanks, I didn't realize we were using that terminology in the app. It's a little misleading.
The automation isn't "hanging" in this case. It's simply blocked from running because of the usage limit.
The app is working as intended here, so I don't think we'd consider this a bug. I'm going to change this to a feature request.
+1 This seems related to #8310. Both issues point to rate-limit window handling and resume behavior that disrupts long-running sessions.
This feature request hasn't received enough upvotes, so closing.
I sure wish codex would just kick back in with what ever it was doing before the usage limit was hit.