openclaw - 💡(How to fix) Fix [Bug]: openai-codex provider encrypted reasoning retry storm causes false 429 rate limits and multi-minute turn delays

Bug type

Behavior bug (incorrect output/state without crash)

Summary

The built-in openai-codex provider (api=openai-codex-responses) retries requests up to 10+ times per turn when encrypted reasoning content fails decryption. Each retry is a full round-trip to chatgpt.com/backend-api/codex/responses, adding 10-20 seconds per retry. This causes two compounding problems:

1. Multi-minute turn delays — A simple message that should take 10-30 seconds takes 2-5+ minutes because the gateway is silently retrying encrypted content failures before the first response reaches the user.
2. False 429 rate limit triggers — The retry storm burns through the Codex Responses API rate limit pool (which is separate from the ChatGPT dashboard quota). The gateway then classifies the 429 as a provider rate limit, cools the auth profile, and fails over to the next auth profile — despite the primary account having 90%+ capacity remaining on the dashboard.

Steps to reproduce

1. Configure OpenClaw with openai-codex/gpt-5.5 on PI runtime (bare {} catalog entry, no agentRuntime override)
2. Authenticate via Codex OAuth with a ChatGPT Pro ($200/mo) account
3. Use the agent through Mattermost (or any channel) for normal multi-turn, tool-heavy work
4. Observe gateway logs showing repeated [responses] retrying without encrypted reasoning content provider=openai-codex api=openai-codex-responses model=gpt-5.5 — typically 8-12 retries per turn
5. After sustained use, observe 429 The usage limit has been reached followed by auth_profile_failure_state_updated and profile failover — despite the Codex dashboard showing near-full capacity

Expected behavior

• Encrypted reasoning content failures should be handled without a full retry storm. Either strip the encrypted content once and proceed, or limit retries to 1-2 attempts max.
• Encrypted content retry failures should not count against the provider rate limit pool.
• The gateway should not cool/failover auth profiles when the 429 is caused by internal retry exhaustion rather than genuine account-level rate limiting.

Actual behavior

• Every turn with tool calls generates 8-12 [responses] retrying without encrypted reasoning content warnings
• Each retry adds 10-20 seconds of latency
• The retry storm eventually triggers 429 usage_limit_reached from the Codex Responses API
• The gateway classifies this as reason=rate_limit and cools the auth profile
• Subsequent turns failover to the next auth profile in the chain
• The primary account's Codex dashboard shows 90%+ capacity remaining — the 429 is from the Responses API's own rate limit, not the account quota

Logs (sanitized)

12:42:46 [openai-transport] [responses] retrying without encrypted reasoning content provider=openai-codex api=openai-codex-responses model=gpt-5.5
12:43:05 [openai-transport] [responses] retrying without encrypted reasoning content provider=openai-codex api=openai-codex-responses model=gpt-5.5
12:43:21 [openai-transport] [responses] retrying without encrypted reasoning content provider=openai-codex api=openai-codex-responses model=gpt-5.5
12:43:35 [openai-transport] [responses] retrying without encrypted reasoning content provider=openai-codex api=openai-codex-responses model=gpt-5.5
12:43:41 [openai-transport] [responses] retrying without encrypted reasoning content provider=openai-codex api=openai-codex-responses model=gpt-5.5
12:43:51 [openai-transport] [responses] retrying without encrypted reasoning content provider=openai-codex api=openai-codex-responses model=gpt-5.5
12:44:26 [openai-transport] [responses] retrying without encrypted reasoning content provider=openai-codex api=openai-codex-responses model=gpt-5.5
12:45:00 [openai-transport] [responses] retrying without encrypted reasoning content provider=openai-codex api=openai-codex-responses model=gpt-5.5
12:45:34 [openai-transport] [responses] retrying without encrypted reasoning content provider=openai-codex api=openai-codex-responses model=gpt-5.5
12:46:09 [openai-transport] [responses] retrying without encrypted reasoning content provider=openai-codex api=openai-codex-responses model=gpt-5.5

10 retries in 3.5 minutes on a single turn, on a fresh session.

Later:

[openai-transport] [responses] error provider=openai-codex api=openai-codex-responses model=gpt-5.5 status=429 type=usage_limit_reached message=429 The usage limit has been reached
[agent/embedded] embedded run failover decision: decision=rotate_profile failoverReason=rate_limit
[agent/embedded] auth profile failure state updated: provider=openai-codex reason=rate_limit errorCount=1

OpenClaw version

2026.5.22

Operating system

macOS (Mac Studio M1 Ultra)

Model

openai-codex/gpt-5.5

Provider / routing chain

openai-codex -> PI runtime -> chatgpt.com/backend-api/codex/responses (Codex OAuth, ChatGPT Pro dollar200/mo)

Additional context

• Fixes #83836 (v2026.5.20) and #85603 (v2026.5.22) do not appear to have resolved this.
• models.providers.openai-codex.api config override does not work for built-in providers — only custom providers. No user-facing way to change the API transport.
• The native Codex harness route (openai/gpt-5.5 + agentRuntime.id: "codex") would avoid this but has unresolved auth/routing bugs (#77107, #75739).
• Setting thinkingDefault: "off" is not acceptable as it degrades model quality.
• Multi-auth-profile setups are disproportionately affected because false 429s trigger profile failover.

Impact and severity

• Affects every openai-codex PI user with reasoning-capable models
• High severity — multi-minute response delays, burns through auth profile chains
• Every turn with tool calls (most turns for coding/infrastructure agents)
• No workaround available