litellm - 💡(How to fix) Fix [Bug]: Codex CLI via LiteLLM proxy appears to enter retry/fallback loop in real sessions [1 comments, 1 participants]

Summary

When using Codex CLI through LiteLLM proxy, requests can appear to enter a retry/fallback loop (repeated web-searching/retry behavior), causing long turns and unstable UX.

What I observe

From session logs, behavior repeats in cycles:

• repeated "Searching the web"
• repeated "I will do X, then run tests" messages
• occasional shell parsing errors from accidental plain-text command attempts
• flow does not converge quickly and appears to loop before producing a stable result

In parallel, there are known Codex+LiteLLM transport issues that may amplify this behavior:

• #24502 (GET /responses 405 mismatch)
• #25532 (WS /v1/responses requiring ?model= leads to retries/fallback)

Environment

• Codex CLI: 0.121.0
• LiteLLM: proxy mode (version in my deployment may vary)
• Transport: OpenAI-compatible endpoint via proxy

Why this may be proxy-related

When responses/websocket negotiation is not fully spec-compatible, Codex appears to retry/fallback multiple times per turn. In long tool-heavy sessions this feels like a loop.

Expected behavior

• No repeated retry/fallback loops during normal turns
• Stable completion after one transport selection (WS or HTTP fallback once)
• Clear non-retriable error path when request shape is incompatible

Actual behavior

• Multiple repeated retries/fallback-like cycles
• Very long turns with repetitive actions/messages

Request

Please investigate whether current /responses (HTTP + WS) behavior with Codex CLI can cause repeated retry loops in practical sessions, and whether retry policy can be tightened for non-retriable mismatches.

If useful, I can provide sanitized full logs in comments.