[Bug]: Codex reports "workspace is out of credits" when the weekly limit ran out, hiding the reset time T3 already shows

[vitalyiegorov]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Use a Codex instance on a ChatGPT Business or Enterprise workspace and run it until the weekly window is exhausted (Usage → Limits shows the Codex weekly bar at 0% left with a reset countdown).
2. Send a message to any Codex thread.

The plan-limit variant: exhaust the 5-hour or weekly window on a Plus or Pro subscription and send a message.

Expected behavior

The turn fails and the error names the real cause and the next step, the way Claude does since #10321: the Codex usage limit was reached, when it resets, and, for a workspace, that there are no credits to continue sooner and who can add them.

Actual behavior

T3 relays OpenAI's sentence verbatim as a red runtime error, twice (timeline row and the failure line under the turn): "Your workspace is out of credits. Ask your workspace owner to refill in order to continue."

That sentence hides what actually happened. The Limits tab, from the same account/rateLimits/updated snapshot the adapter receives during that turn, shows the weekly window at 0% with a reset in 5d 5h. Credits are only the overflow a workspace may buy once a window is exhausted; the cause is the window, and the reset time T3 already holds is never shown. On a Plus or Pro plan the relayed text is "You've hit your usage limit. Try again in 3 hours 20 minutes." with no provider name and no link to the reset T3 knows about.

Mechanically, apps/server/src/provider/Layers/CodexAdapter.ts maps the error notification (codexErrorInfo: "usageLimitExceeded") straight to runtime.error with the provider's message, and the following failed turn/completed carries the same text as errorMessage. The rateLimitReachedType on the snapshot (rate_limit_reached, workspace_*_credits_depleted, workspace_*_usage_limit_reached) and the exhausted window's resetsAt are ignored on this path. Claude's adapter now latches the real cause during the turn and reports it when the turn ends (#10321); Codex has no equivalent.

Users read "out of credits" as a billing problem to escalate to their admin, when the honest answer is "your weekly limit resets in five days".

Codex thread after a limit stop, and the Limits tab for the same account at the same moment:

Impact

Major degradation or frequent failure

Version or commit

main @ 6abdf37

Environment

macOS 15, desktop app; Codex CLI 0.153, ChatGPT Business workspace login; server on Linux

Logs or stack traces

# Codex app-server notifications observed during the turn, in order
error                       { error: { message: "Your workspace is out of credits. Ask your workspace owner to refill in order to continue.", codexErrorInfo: "usageLimitExceeded" }, willRetry: false }
account/rateLimits/updated  { rateLimits: { planType: "business", rateLimitReachedType: "workspace_member_credits_depleted", primary: { usedPercent: 100, windowDurationMins: 10080, resetsAt: <epoch, +5d 5h> } } }
turn/completed              { turn: { status: "failed", error: { message: <same sentence>, codexErrorInfo: "usageLimitExceeded" } } }
# T3 emits: runtime.error <same sentence>, then turn.completed failed with errorMessage <same sentence>

Screenshots, recordings, or supporting files

No response

Workaround

Open Usage → Limits to find the actual reset time.

[juliusmarminge]

Triage

Confirmed from source. This is a real Codex messaging bug, not a wash of #9234 / #9236.

CodexAdapter maps a fatal error notification straight to runtime.error with the provider sentence, then copies the same text onto the failed turn/completed as errorMessage. codexErrorInfo: "usageLimitExceeded" is unused. The same turn’s account/rateLimits/updated snapshot is folded only into Usage → Limits (usedPercent / resetsAt); rateLimitReachedType never reaches the error path.

That matches the report: Limits already shows the weekly window at 100% with a reset, while the thread says the workspace is out of credits. Credits are overflow after a window is exhausted, not the cause. Plus/Pro hits the same path with “You’ve hit your usage limit…” and still does not name Codex or use the reset T3 already has.

error arrives before account/rateLimits/updated, then turn/completed. Rewriting the first notification alone will miss resetsAt. Claude already latches the cause during the turn and reports it when the turn ends (#10321). Codex has no equivalent turn state.

Not a duplicate

• [Bug]: Codex Business workspace credit exhaustion shows as a generic runtime error, not a usage-limit stop #9234 / fix(codex): treat usage-limit stops as quota, not errors #9236 asked to reclassify quota as a warning / cancelled turn. Those were closed because fix(grok): improve skills, plans, usage, and turn reliability #8358 already set the model: fail the turn with a visible usage-limit message. This issue keeps that model and only asks to name the real cause and reset.
• fix(codex): recover turns after usage limits #7308 is recovery/retry after usageLimitExceeded for account-selecting launchers — a different ask.

Next step

Keep the failed-turn model. Latch usageLimitExceeded plus the in-turn (or last-known) snapshot in apps/server/src/provider/Layers/CodexAdapter.ts, and compose the user-facing text at turn/completed (and on the matching runtime.error): Codex usage limit reached, which window, when it resets, and only then that a workspace has no credits to continue sooner. Cover workspace-window + credits sentence, Plus/Pro rate_limit_reached, and a credits-only stop with no resetsAt.

Accepting as a bug.

[vitalyiegorov]

Thanks for the triage. #10473 follows that shape, with one simplification: instead of a per-turn latch, the adapter keeps the session's last account/rateLimits/updated snapshot (merged field by field, since Codex sends sparse updates) and composes the message when the failed turn/completed arrives, so the in-turn or last-known window is used either way. All three cases you listed are covered by tests: workspace window + credits, Plus/Pro rate_limit_reached, and a credits-only stop with no reset.