fix(codex): treat usage-limit stops as quota, not errors

[vitalyiegorov]

What Changed

When Codex stops a turn because the account is out of quota, the thread now shows a warning row with Codex's own sentence and the turn ends quietly, instead of the thread going red with a generic runtime error banner.

Codex reports three different stops under one error code, usageLimitExceeded: personal plan windows ("Your limit will reset at 6:00 PM"), Business/Enterprise workspace credits ("Your workspace is out of credits. Ask your workspace owner to refill…"), and workspace spend caps. CodexAdapter now recognizes that code in both places it arrives:

• the error notification becomes a runtime.warning (the labeled work-log row the clients already render) rather than a runtime.error, so the session is not marked errored;
• the turn/completed that follows is reported as cancelled rather than failed, with no errorMessage, so session.lastError stays empty and no red banner appears. The warning row already said why the turn ended.

Every other Codex error keeps its existing path: runtime.error with provider_error, failed turn, red banner. Adapter-only — no contract, schema, migration, or client changes. A short FAQ in docs/user/providers-codex.md explains what the two kinds of message mean and what to do.

Why

Fixes#9234. Out of quota is not a malfunction. Painting it as one makes users chase a crash that never happened, and for Business accounts (which stop on credits, not on a resetting window) the red banner is the only thing they see. Codex already tells us it is a limit; the adapter was throwing that classification away.

Handling it at the adapter boundary keeps orchestration untouched: ingestion already maps a non-failed turn to ready / lastError: null, and the projection derives latestTurn.state from the session status, so the thread lands as a settled turn with the warning row as its last entry. cancelled is used rather than interrupted because clients label an interrupted latest turn "You stopped this response", which would be false here.

This is the Codex half of the problem #7165 addresses for Claude; that PR will be trimmed to Claude only so each provider is one concern.

UI Changes

No new components: the after-state is the existing runtime.warning row in the work log. Both captures below come from the same local T3 server driving a fake codex app-server that replays, byte for byte in the vendored schema, the sequence codex-rs emits for a Business workspace credit stop (error with codexErrorInfo: "usageLimitExceeded", account/rateLimits/updated with workspace_member_credits_depleted, then turn/completedfailed). Only the branch differs.

Before (main) — generic thread error banner, red "Runtime error" row, thread badged Failed in the sidebar:

After (this branch) — the same sentence as a warning row, no banner, no error state, composer ready:

For reference, the original report from a real Business account (#9234) shows the same red banner as the before state.

Related work

• Treat retryable Codex error notifications as runtime warnings #758 (merged) established that retryable Codex error notifications are warnings; this PR extends the same boundary to quota stops.
• fix(codex): recover turns after usage limits #7308 and feat: resume threads after usage limits reset #8577 (open) detect the same usageLimitExceeded code but for recovery and auto-resume; they do not change how a stop is presented. fix(codex): accept rate limit errors on thread resume #8897 / Codex rateLimitExceeded error makes threads permanently unresumable #8875 concern a different code (rateLimitExceeded) on thread resume.
• fix(grok): improve skills, plans, usage, and turn reliability #8358 (merged) is the Grok precedent: a usage-limit stop fails the turn with a visible message. See discussion below on why Codex is handled at the adapter boundary instead.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes — n/a, no motion

Built with Claude Fable 5 in Claude Code.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at 14c6036

Macroscope's review found this PR approvable — This is a focused Codex adapter bug fix that reclassifies provider-reported quota exhaustion using existing warning and cancelled-turn states. Tests cover the new mappings and preserve non-quota error behavior, while the documentation-only change has no runtime impact.

^{You can add or adjust custom eligibility rules. Learn more.}

[vitalyiegorov]

What Changed

When Codex stops a turn because the account is out of quota, the thread now shows a warning row with Codex's own sentence and the turn ends quietly, instead of the thread going red with a generic runtime error banner.

Codex reports three different stops under one error code, usageLimitExceeded: personal plan windows ("Your limit will reset at 6:00 PM"), Business/Enterprise workspace credits ("Your workspace is out of credits. Ask your workspace owner to refill…"), and workspace spend caps. CodexAdapter now recognizes that code in both places it arrives:

• the error notification becomes a runtime.warning (the labeled work-log row the clients already render) rather than a runtime.error, so the session is not marked errored;
• the turn/completed that follows is reported as cancelled rather than failed, with no errorMessage, so session.lastError stays empty and no red banner appears. The warning row already said why the turn ended.

Every other Codex error keeps its existing path: runtime.error with provider_error, failed turn, red banner. Adapter-only — no contract, schema, migration, or client changes. A short FAQ in docs/user/providers-codex.md explains what the two kinds of message mean and what to do.

Why

Fixes#9234. Out of quota is not a malfunction. Painting it as one makes users chase a crash that never happened, and for Business accounts (which stop on credits, not on a resetting window) the red banner is the only thing they see. Codex already tells us it is a limit; the adapter was throwing that classification away.

Handling it at the adapter boundary keeps orchestration untouched: ingestion already maps a non-failed turn to ready / lastError: null, and the projection derives latestTurn.state from the session status, so the thread lands as a settled turn with the warning row as its last entry. cancelled is used rather than interrupted because clients label an interrupted latest turn "You stopped this response", which would be false here.

This is the Codex half of the problem #7165 addresses for Claude; that PR will be trimmed to Claude only so each provider is one concern.

UI Changes

No new components: the after-state is the existing runtime.warning row in the work log. Both captures below come from the same local T3 server driving a fake codex app-server that replays, byte for byte in the vendored schema, the sequence codex-rs emits for a Business workspace credit stop (error with codexErrorInfo: "usageLimitExceeded", account/rateLimits/updated with workspace_member_credits_depleted, then turn/completedfailed). Only the branch differs.

Before (main) — generic thread error banner, red "Runtime error" row, thread badged Failed in the sidebar:

After (this branch) — the same sentence as a warning row, no banner, no error state, composer ready:

For reference, the original report from a real Business account (#9234) shows the same red banner as the before state.

Related work

• Treat retryable Codex error notifications as runtime warnings #758 (merged) established that retryable Codex error notifications are warnings; this PR extends the same boundary to quota stops.
• fix(codex): recover turns after usage limits #7308 and feat: resume threads after usage limits reset #8577 (open) detect the same usageLimitExceeded code but for recovery and auto-resume; they do not change how a stop is presented. fix(codex): accept rate limit errors on thread resume #8897 / Codex rateLimitExceeded error makes threads permanently unresumable #8875 concern a different code (rateLimitExceeded) on thread resume.
• fix(grok): improve skills, plans, usage, and turn reliability #8358 (merged) is the Grok precedent: a usage-limit stop fails the turn with a visible message. See discussion below on why Codex is handled at the adapter boundary instead.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes — n/a, no motion

Built with Claude Fable 5 in Claude Code.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at 14c6036

Macroscope's review found this PR approvable — This is a focused Codex adapter bug fix that reclassifies provider-reported quota exhaustion using existing warning and cancelled-turn states. Tests cover the new mappings and preserve non-quota error behavior, while the documentation-only change has no runtime impact.

^{You can add or adjust custom eligibility rules. Learn more.}

[vitalyiegorov]

What Changed

When Codex stops a turn because the account is out of quota, the thread now shows a warning row with Codex's own sentence and the turn ends quietly, instead of the thread going red with a generic runtime error banner.

Codex reports three different stops under one error code, usageLimitExceeded: personal plan windows ("Your limit will reset at 6:00 PM"), Business/Enterprise workspace credits ("Your workspace is out of credits. Ask your workspace owner to refill…"), and workspace spend caps. CodexAdapter now recognizes that code in both places it arrives:

• the error notification becomes a runtime.warning (the labeled work-log row the clients already render) rather than a runtime.error, so the session is not marked errored;
• the turn/completed that follows is reported as cancelled rather than failed, with no errorMessage, so session.lastError stays empty and no red banner appears. The warning row already said why the turn ended.

Every other Codex error keeps its existing path: runtime.error with provider_error, failed turn, red banner. Adapter-only — no contract, schema, migration, or client changes. A short FAQ in docs/user/providers-codex.md explains what the two kinds of message mean and what to do.

Why

Fixes#9234. Out of quota is not a malfunction. Painting it as one makes users chase a crash that never happened, and for Business accounts (which stop on credits, not on a resetting window) the red banner is the only thing they see. Codex already tells us it is a limit; the adapter was throwing that classification away.

Handling it at the adapter boundary keeps orchestration untouched: ingestion already maps a non-failed turn to ready / lastError: null, and the projection derives latestTurn.state from the session status, so the thread lands as a settled turn with the warning row as its last entry. cancelled is used rather than interrupted because clients label an interrupted latest turn "You stopped this response", which would be false here.

This is the Codex half of the problem #7165 addresses for Claude; that PR will be trimmed to Claude only so each provider is one concern.

UI Changes

No new components: the after-state is the existing runtime.warning row in the work log. Both captures below come from the same local T3 server driving a fake codex app-server that replays, byte for byte in the vendored schema, the sequence codex-rs emits for a Business workspace credit stop (error with codexErrorInfo: "usageLimitExceeded", account/rateLimits/updated with workspace_member_credits_depleted, then turn/completedfailed). Only the branch differs.

Before (main) — generic thread error banner, red "Runtime error" row, thread badged Failed in the sidebar:

After (this branch) — the same sentence as a warning row, no banner, no error state, composer ready:

For reference, the original report from a real Business account (#9234) shows the same red banner as the before state.

Related work

• Treat retryable Codex error notifications as runtime warnings #758 (merged) established that retryable Codex error notifications are warnings; this PR extends the same boundary to quota stops.
• fix(codex): recover turns after usage limits #7308 and feat: resume threads after usage limits reset #8577 (open) detect the same usageLimitExceeded code but for recovery and auto-resume; they do not change how a stop is presented. fix(codex): accept rate limit errors on thread resume #8897 / Codex rateLimitExceeded error makes threads permanently unresumable #8875 concern a different code (rateLimitExceeded) on thread resume.
• fix(grok): improve skills, plans, usage, and turn reliability #8358 (merged) is the Grok precedent: a usage-limit stop fails the turn with a visible message. See discussion below on why Codex is handled at the adapter boundary instead.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes — n/a, no motion

Built with Claude Fable 5 in Claude Code.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at 14c6036

Macroscope's review found this PR approvable — This is a focused Codex adapter bug fix that reclassifies provider-reported quota exhaustion using existing warning and cancelled-turn states. Tests cover the new mappings and preserve non-quota error behavior, while the documentation-only change has no runtime impact.

^{You can add or adjust custom eligibility rules. Learn more.}

[vitalyiegorov]

What Changed

When Codex stops a turn because the account is out of quota, the thread now shows a warning row with Codex's own sentence and the turn ends quietly, instead of the thread going red with a generic runtime error banner.

Codex reports three different stops under one error code, usageLimitExceeded: personal plan windows ("Your limit will reset at 6:00 PM"), Business/Enterprise workspace credits ("Your workspace is out of credits. Ask your workspace owner to refill…"), and workspace spend caps. CodexAdapter now recognizes that code in both places it arrives:

• the error notification becomes a runtime.warning (the labeled work-log row the clients already render) rather than a runtime.error, so the session is not marked errored;
• the turn/completed that follows is reported as cancelled rather than failed, with no errorMessage, so session.lastError stays empty and no red banner appears. The warning row already said why the turn ended.

Every other Codex error keeps its existing path: runtime.error with provider_error, failed turn, red banner. Adapter-only — no contract, schema, migration, or client changes. A short FAQ in docs/user/providers-codex.md explains what the two kinds of message mean and what to do.

Why

Fixes#9234. Out of quota is not a malfunction. Painting it as one makes users chase a crash that never happened, and for Business accounts (which stop on credits, not on a resetting window) the red banner is the only thing they see. Codex already tells us it is a limit; the adapter was throwing that classification away.

Handling it at the adapter boundary keeps orchestration untouched: ingestion already maps a non-failed turn to ready / lastError: null, and the projection derives latestTurn.state from the session status, so the thread lands as a settled turn with the warning row as its last entry. cancelled is used rather than interrupted because clients label an interrupted latest turn "You stopped this response", which would be false here.

This is the Codex half of the problem #7165 addresses for Claude; that PR will be trimmed to Claude only so each provider is one concern.

UI Changes

No new components: the after-state is the existing runtime.warning row in the work log. Both captures below come from the same local T3 server driving a fake codex app-server that replays, byte for byte in the vendored schema, the sequence codex-rs emits for a Business workspace credit stop (error with codexErrorInfo: "usageLimitExceeded", account/rateLimits/updated with workspace_member_credits_depleted, then turn/completedfailed). Only the branch differs.

Before (main) — generic thread error banner, red "Runtime error" row, thread badged Failed in the sidebar:

After (this branch) — the same sentence as a warning row, no banner, no error state, composer ready:

For reference, the original report from a real Business account (#9234) shows the same red banner as the before state.

Related work

• Treat retryable Codex error notifications as runtime warnings #758 (merged) established that retryable Codex error notifications are warnings; this PR extends the same boundary to quota stops.
• fix(codex): recover turns after usage limits #7308 and feat: resume threads after usage limits reset #8577 (open) detect the same usageLimitExceeded code but for recovery and auto-resume; they do not change how a stop is presented. fix(codex): accept rate limit errors on thread resume #8897 / Codex rateLimitExceeded error makes threads permanently unresumable #8875 concern a different code (rateLimitExceeded) on thread resume.
• fix(grok): improve skills, plans, usage, and turn reliability #8358 (merged) is the Grok precedent: a usage-limit stop fails the turn with a visible message. See discussion below on why Codex is handled at the adapter boundary instead.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes — n/a, no motion

Built with Claude Fable 5 in Claude Code.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at 14c6036

Macroscope's review found this PR approvable — This is a focused Codex adapter bug fix that reclassifies provider-reported quota exhaustion using existing warning and cancelled-turn states. Tests cover the new mappings and preserve non-quota error behavior, while the documentation-only change has no runtime impact.

^{You can add or adjust custom eligibility rules. Learn more.}

[vitalyiegorov]

What Changed

When Codex stops a turn because the account is out of quota, the thread now shows a warning row with Codex's own sentence and the turn ends quietly, instead of the thread going red with a generic runtime error banner.

Codex reports three different stops under one error code, usageLimitExceeded: personal plan windows ("Your limit will reset at 6:00 PM"), Business/Enterprise workspace credits ("Your workspace is out of credits. Ask your workspace owner to refill…"), and workspace spend caps. CodexAdapter now recognizes that code in both places it arrives:

• the error notification becomes a runtime.warning (the labeled work-log row the clients already render) rather than a runtime.error, so the session is not marked errored;
• the turn/completed that follows is reported as cancelled rather than failed, with no errorMessage, so session.lastError stays empty and no red banner appears. The warning row already said why the turn ended.

Every other Codex error keeps its existing path: runtime.error with provider_error, failed turn, red banner. Adapter-only — no contract, schema, migration, or client changes. A short FAQ in docs/user/providers-codex.md explains what the two kinds of message mean and what to do.

Why

Fixes#9234. Out of quota is not a malfunction. Painting it as one makes users chase a crash that never happened, and for Business accounts (which stop on credits, not on a resetting window) the red banner is the only thing they see. Codex already tells us it is a limit; the adapter was throwing that classification away.

Handling it at the adapter boundary keeps orchestration untouched: ingestion already maps a non-failed turn to ready / lastError: null, and the projection derives latestTurn.state from the session status, so the thread lands as a settled turn with the warning row as its last entry. cancelled is used rather than interrupted because clients label an interrupted latest turn "You stopped this response", which would be false here.

This is the Codex half of the problem #7165 addresses for Claude; that PR will be trimmed to Claude only so each provider is one concern.

UI Changes

No new components: the after-state is the existing runtime.warning row in the work log. Both captures below come from the same local T3 server driving a fake codex app-server that replays, byte for byte in the vendored schema, the sequence codex-rs emits for a Business workspace credit stop (error with codexErrorInfo: "usageLimitExceeded", account/rateLimits/updated with workspace_member_credits_depleted, then turn/completedfailed). Only the branch differs.

Before (main) — generic thread error banner, red "Runtime error" row, thread badged Failed in the sidebar:

After (this branch) — the same sentence as a warning row, no banner, no error state, composer ready:

For reference, the original report from a real Business account (#9234) shows the same red banner as the before state.

Related work

• Treat retryable Codex error notifications as runtime warnings #758 (merged) established that retryable Codex error notifications are warnings; this PR extends the same boundary to quota stops.
• fix(codex): recover turns after usage limits #7308 and feat: resume threads after usage limits reset #8577 (open) detect the same usageLimitExceeded code but for recovery and auto-resume; they do not change how a stop is presented. fix(codex): accept rate limit errors on thread resume #8897 / Codex rateLimitExceeded error makes threads permanently unresumable #8875 concern a different code (rateLimitExceeded) on thread resume.
• fix(grok): improve skills, plans, usage, and turn reliability #8358 (merged) is the Grok precedent: a usage-limit stop fails the turn with a visible message. See discussion below on why Codex is handled at the adapter boundary instead.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes — n/a, no motion

Built with Claude Fable 5 in Claude Code.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at 14c6036

Macroscope's review found this PR approvable — This is a focused Codex adapter bug fix that reclassifies provider-reported quota exhaustion using existing warning and cancelled-turn states. Tests cover the new mappings and preserve non-quota error behavior, while the documentation-only change has no runtime impact.

^{You can add or adjust custom eligibility rules. Learn more.}

[vitalyiegorov]

What Changed

When Codex stops a turn because the account is out of quota, the thread now shows a warning row with Codex's own sentence and the turn ends quietly, instead of the thread going red with a generic runtime error banner.

Codex reports three different stops under one error code, usageLimitExceeded: personal plan windows ("Your limit will reset at 6:00 PM"), Business/Enterprise workspace credits ("Your workspace is out of credits. Ask your workspace owner to refill…"), and workspace spend caps. CodexAdapter now recognizes that code in both places it arrives:

• the error notification becomes a runtime.warning (the labeled work-log row the clients already render) rather than a runtime.error, so the session is not marked errored;
• the turn/completed that follows is reported as cancelled rather than failed, with no errorMessage, so session.lastError stays empty and no red banner appears. The warning row already said why the turn ended.

Every other Codex error keeps its existing path: runtime.error with provider_error, failed turn, red banner. Adapter-only — no contract, schema, migration, or client changes. A short FAQ in docs/user/providers-codex.md explains what the two kinds of message mean and what to do.

Why

Fixes#9234. Out of quota is not a malfunction. Painting it as one makes users chase a crash that never happened, and for Business accounts (which stop on credits, not on a resetting window) the red banner is the only thing they see. Codex already tells us it is a limit; the adapter was throwing that classification away.

Handling it at the adapter boundary keeps orchestration untouched: ingestion already maps a non-failed turn to ready / lastError: null, and the projection derives latestTurn.state from the session status, so the thread lands as a settled turn with the warning row as its last entry. cancelled is used rather than interrupted because clients label an interrupted latest turn "You stopped this response", which would be false here.

This is the Codex half of the problem #7165 addresses for Claude; that PR will be trimmed to Claude only so each provider is one concern.

UI Changes

No new components: the after-state is the existing runtime.warning row in the work log. Both captures below come from the same local T3 server driving a fake codex app-server that replays, byte for byte in the vendored schema, the sequence codex-rs emits for a Business workspace credit stop (error with codexErrorInfo: "usageLimitExceeded", account/rateLimits/updated with workspace_member_credits_depleted, then turn/completedfailed). Only the branch differs.

Before (main) — generic thread error banner, red "Runtime error" row, thread badged Failed in the sidebar:

After (this branch) — the same sentence as a warning row, no banner, no error state, composer ready:

For reference, the original report from a real Business account (#9234) shows the same red banner as the before state.

Related work

• Treat retryable Codex error notifications as runtime warnings #758 (merged) established that retryable Codex error notifications are warnings; this PR extends the same boundary to quota stops.
• fix(codex): recover turns after usage limits #7308 and feat: resume threads after usage limits reset #8577 (open) detect the same usageLimitExceeded code but for recovery and auto-resume; they do not change how a stop is presented. fix(codex): accept rate limit errors on thread resume #8897 / Codex rateLimitExceeded error makes threads permanently unresumable #8875 concern a different code (rateLimitExceeded) on thread resume.
• fix(grok): improve skills, plans, usage, and turn reliability #8358 (merged) is the Grok precedent: a usage-limit stop fails the turn with a visible message. See discussion below on why Codex is handled at the adapter boundary instead.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes — n/a, no motion

Built with Claude Fable 5 in Claude Code.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at 14c6036

Macroscope's review found this PR approvable — This is a focused Codex adapter bug fix that reclassifies provider-reported quota exhaustion using existing warning and cancelled-turn states. Tests cover the new mappings and preserve non-quota error behavior, while the documentation-only change has no runtime impact.

^{You can add or adjust custom eligibility rules. Learn more.}

[vitalyiegorov]

What Changed

When Codex stops a turn because the account is out of quota, the thread now shows a warning row with Codex's own sentence and the turn ends quietly, instead of the thread going red with a generic runtime error banner.

Codex reports three different stops under one error code, usageLimitExceeded: personal plan windows ("Your limit will reset at 6:00 PM"), Business/Enterprise workspace credits ("Your workspace is out of credits. Ask your workspace owner to refill…"), and workspace spend caps. CodexAdapter now recognizes that code in both places it arrives:

• the error notification becomes a runtime.warning (the labeled work-log row the clients already render) rather than a runtime.error, so the session is not marked errored;
• the turn/completed that follows is reported as cancelled rather than failed, with no errorMessage, so session.lastError stays empty and no red banner appears. The warning row already said why the turn ended.

Every other Codex error keeps its existing path: runtime.error with provider_error, failed turn, red banner. Adapter-only — no contract, schema, migration, or client changes. A short FAQ in docs/user/providers-codex.md explains what the two kinds of message mean and what to do.

Why

Fixes#9234. Out of quota is not a malfunction. Painting it as one makes users chase a crash that never happened, and for Business accounts (which stop on credits, not on a resetting window) the red banner is the only thing they see. Codex already tells us it is a limit; the adapter was throwing that classification away.

Handling it at the adapter boundary keeps orchestration untouched: ingestion already maps a non-failed turn to ready / lastError: null, and the projection derives latestTurn.state from the session status, so the thread lands as a settled turn with the warning row as its last entry. cancelled is used rather than interrupted because clients label an interrupted latest turn "You stopped this response", which would be false here.

This is the Codex half of the problem #7165 addresses for Claude; that PR will be trimmed to Claude only so each provider is one concern.

UI Changes

No new components: the after-state is the existing runtime.warning row in the work log. Both captures below come from the same local T3 server driving a fake codex app-server that replays, byte for byte in the vendored schema, the sequence codex-rs emits for a Business workspace credit stop (error with codexErrorInfo: "usageLimitExceeded", account/rateLimits/updated with workspace_member_credits_depleted, then turn/completedfailed). Only the branch differs.

Before (main) — generic thread error banner, red "Runtime error" row, thread badged Failed in the sidebar:

After (this branch) — the same sentence as a warning row, no banner, no error state, composer ready:

For reference, the original report from a real Business account (#9234) shows the same red banner as the before state.

Related work

• Treat retryable Codex error notifications as runtime warnings #758 (merged) established that retryable Codex error notifications are warnings; this PR extends the same boundary to quota stops.
• fix(codex): recover turns after usage limits #7308 and feat: resume threads after usage limits reset #8577 (open) detect the same usageLimitExceeded code but for recovery and auto-resume; they do not change how a stop is presented. fix(codex): accept rate limit errors on thread resume #8897 / Codex rateLimitExceeded error makes threads permanently unresumable #8875 concern a different code (rateLimitExceeded) on thread resume.
• fix(grok): improve skills, plans, usage, and turn reliability #8358 (merged) is the Grok precedent: a usage-limit stop fails the turn with a visible message. See discussion below on why Codex is handled at the adapter boundary instead.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes — n/a, no motion

Built with Claude Fable 5 in Claude Code.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at 14c6036

Macroscope's review found this PR approvable — This is a focused Codex adapter bug fix that reclassifies provider-reported quota exhaustion using existing warning and cancelled-turn states. Tests cover the new mappings and preserve non-quota error behavior, while the documentation-only change has no runtime impact.

^{You can add or adjust custom eligibility rules. Learn more.}

[vitalyiegorov]

What Changed

When Codex stops a turn because the account is out of quota, the thread now shows a warning row with Codex's own sentence and the turn ends quietly, instead of the thread going red with a generic runtime error banner.

Codex reports three different stops under one error code, usageLimitExceeded: personal plan windows ("Your limit will reset at 6:00 PM"), Business/Enterprise workspace credits ("Your workspace is out of credits. Ask your workspace owner to refill…"), and workspace spend caps. CodexAdapter now recognizes that code in both places it arrives:

• the error notification becomes a runtime.warning (the labeled work-log row the clients already render) rather than a runtime.error, so the session is not marked errored;
• the turn/completed that follows is reported as cancelled rather than failed, with no errorMessage, so session.lastError stays empty and no red banner appears. The warning row already said why the turn ended.

Every other Codex error keeps its existing path: runtime.error with provider_error, failed turn, red banner. Adapter-only — no contract, schema, migration, or client changes. A short FAQ in docs/user/providers-codex.md explains what the two kinds of message mean and what to do.

Why

Fixes#9234. Out of quota is not a malfunction. Painting it as one makes users chase a crash that never happened, and for Business accounts (which stop on credits, not on a resetting window) the red banner is the only thing they see. Codex already tells us it is a limit; the adapter was throwing that classification away.

Handling it at the adapter boundary keeps orchestration untouched: ingestion already maps a non-failed turn to ready / lastError: null, and the projection derives latestTurn.state from the session status, so the thread lands as a settled turn with the warning row as its last entry. cancelled is used rather than interrupted because clients label an interrupted latest turn "You stopped this response", which would be false here.

This is the Codex half of the problem #7165 addresses for Claude; that PR will be trimmed to Claude only so each provider is one concern.

UI Changes

No new components: the after-state is the existing runtime.warning row in the work log. Both captures below come from the same local T3 server driving a fake codex app-server that replays, byte for byte in the vendored schema, the sequence codex-rs emits for a Business workspace credit stop (error with codexErrorInfo: "usageLimitExceeded", account/rateLimits/updated with workspace_member_credits_depleted, then turn/completedfailed). Only the branch differs.

Before (main) — generic thread error banner, red "Runtime error" row, thread badged Failed in the sidebar:

After (this branch) — the same sentence as a warning row, no banner, no error state, composer ready:

For reference, the original report from a real Business account (#9234) shows the same red banner as the before state.

Related work

• Treat retryable Codex error notifications as runtime warnings #758 (merged) established that retryable Codex error notifications are warnings; this PR extends the same boundary to quota stops.
• fix(codex): recover turns after usage limits #7308 and feat: resume threads after usage limits reset #8577 (open) detect the same usageLimitExceeded code but for recovery and auto-resume; they do not change how a stop is presented. fix(codex): accept rate limit errors on thread resume #8897 / Codex rateLimitExceeded error makes threads permanently unresumable #8875 concern a different code (rateLimitExceeded) on thread resume.
• fix(grok): improve skills, plans, usage, and turn reliability #8358 (merged) is the Grok precedent: a usage-limit stop fails the turn with a visible message. See discussion below on why Codex is handled at the adapter boundary instead.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes — n/a, no motion

Built with Claude Fable 5 in Claude Code.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at 14c6036

Macroscope's review found this PR approvable — This is a focused Codex adapter bug fix that reclassifies provider-reported quota exhaustion using existing warning and cancelled-turn states. Tests cover the new mappings and preserve non-quota error behavior, while the documentation-only change has no runtime impact.

^{You can add or adjust custom eligibility rules. Learn more.}