Summary
The public Codex client implementation can retain an unsuccessful fallback endpoint even after the primary endpoint recovers. Combined with the agent's authentication pause logic, this appears capable of preventing automatic recovery.
This report describes a code-level failure scenario, not a claim that the regression test below has already been run.
Code path
Source inspected at commit cf34b4559caab8208d971f0227e03c58500ecd39.
In internal/api/codex_client.go:
FetchUsage prefers fallbackBaseURL whenever it is nonempty.
- On HTTP 404, it calls
setFallbackBaseURL before verifying that the fallback request succeeds.
- If that fallback returns HTTP 403, the cached endpoint remains selected.
SetToken updates the bearer token without clearing endpoint selection.
In internal/agent/codex_agent.go:
- Repeated forbidden responses can set
authPaused.
- Normal usage polling then returns early until the pause is lifted.
- Detecting changed credentials can lift the pause, but does not reset the client's cached fallback.
Consequently, credential changes alone may keep sending requests to an unsuccessful fallback rather than discovering that the primary works again.
Proposed regression test
Using a local mock HTTP server:
- Return 404 from the primary on its first request.
- Return 403 from the fallback.
- Make the primary return 200 on subsequent requests.
- Perform subsequent polls, including a token change.
- Check whether polling can recover to the primary without reconstructing the client or restarting the process.
An additional agent-level test could cover recovery after the authentication failure threshold is reached.
Expected behavior
An unsuccessful fallback should not indefinitely prevent recovery to a healthy primary. Consider caching only a successful fallback, or invalidating/revalidating endpoint selection with bounded retries and backoff.
It would also help to distinguish an HTML challenge response from an OAuth authentication error before entering a persistent authentication pause.
Related: #111 added bounded pause recovery for Anthropic. This report concerns Codex endpoint selection and its interaction with authentication pausing.
Summary
The public Codex client implementation can retain an unsuccessful fallback endpoint even after the primary endpoint recovers. Combined with the agent's authentication pause logic, this appears capable of preventing automatic recovery.
This report describes a code-level failure scenario, not a claim that the regression test below has already been run.
Code path
Source inspected at commit
cf34b4559caab8208d971f0227e03c58500ecd39.In internal/api/codex_client.go:
FetchUsageprefersfallbackBaseURLwhenever it is nonempty.setFallbackBaseURLbefore verifying that the fallback request succeeds.SetTokenupdates the bearer token without clearing endpoint selection.In internal/agent/codex_agent.go:
authPaused.Consequently, credential changes alone may keep sending requests to an unsuccessful fallback rather than discovering that the primary works again.
Proposed regression test
Using a local mock HTTP server:
An additional agent-level test could cover recovery after the authentication failure threshold is reached.
Expected behavior
An unsuccessful fallback should not indefinitely prevent recovery to a healthy primary. Consider caching only a successful fallback, or invalidating/revalidating endpoint selection with bounded retries and backoff.
It would also help to distinguish an HTML challenge response from an OAuth authentication error before entering a persistent authentication pause.
Related: #111 added bounded pause recovery for Anthropic. This report concerns Codex endpoint selection and its interaction with authentication pausing.