macOS desktop: suspected concurrent MCP OAuth refreshes cause rotated-token reuse and repeated reauthentication

What version of the Codex App are you using (From “About Codex” dialog)?

26.908.70816 — released September 14, 2026. The About dialog displays “ChatGPT — Powered by Codex & OWL”.

What subscription do you have?

Plus

What platform is your computer?

Darwin 27.0.0 arm64 arm

What issue are you seeing?

Remote MCP authentication repeatedly stops working around access-token renewal in the macOS desktop app. Manual OAuth reauthentication restores access temporarily. I do not observe this behavior with Claude.

The MCP server is protected by babs/mcp-auth-proxy v1.4.0, with Keycloak as the upstream identity provider. The proxy issues its own access tokens with expires_in=3600 and rotating refresh tokens with a 7-day lifetime.

Proxy logs show that refresh requests succeed, but previously consumed refresh tokens are subsequently reused, triggering token-family revocation.

Representative sequence, September 15, 2026 (all timestamps UTC), for the same OAuth client:

11:34:29.160 — token_refreshed; POST /token returns HTTP 200.
11:34:29.179 — refresh_token_concurrent_submit; HTTP 429.
11:34:29.180 — refresh_token_concurrent_submit; HTTP 429.
11:34:29.190 — refresh_token_concurrent_submit; HTTP 429.
11:35:45.713 — refresh_token_reuse_detected for the same token_id and family_id; HTTP 400, family revoked.

Thus, three duplicate refresh submissions occur within 30 ms of a successful refresh, and the same consumed refresh token is submitted again approximately 76 seconds later.

Across the available proxy logs from September 8–16, there are 30 refresh-token reuse detections, all associated with my account, and 392 subsequent refresh_token_family_revoked events across the deployment.

This suggests concurrent credential holders or stale refresh-token persistence/adoption in the desktop MCP OAuth client. Server logs alone cannot identify the originating client process, so the exact client-side cause remains unconfirmed.

What steps can reproduce the bug?

Observed usage sequence; not yet reduced to a deterministic minimal reproduction:

1. Configure a remote Streamable HTTP MCP server behind babs/mcp-auth-proxy v1.4.0 with Keycloak.
2. Authenticate through the macOS desktop app.
3. Use the MCP integration normally across desktop tasks.
4. Allow the access token to reach its 1-hour expiry and continue using MCP tools.
5. Inspect the proxy logs: a successful refresh may be followed by duplicate submissions and later reuse of a consumed refresh token.
6. Once the proxy revokes the token family, further refresh attempts fail and manual OAuth reauthentication is required.

I have not yet confirmed whether this reproduces with only one Codex process running. The number of credential-holding processes involved in the recorded incidents is unknown.

What is the expected behavior?

MCP authentication should remain usable across access-token expiry while the refresh token remains valid.

Concurrent connections sharing an OAuth credential should coordinate refreshes and adopt the newly persisted access and refresh tokens. They should not submit a previously consumed refresh token after another connection has successfully rotated it.

If the refresh token is permanently rejected, the app should surface a clear reauthentication action instead of repeatedly retrying the revoked token.

Additional information

Proxy: https://github.com/babs/mcp-auth-proxy
Version: v1.4.0
Commit: 23294a10a99ecffda863e6dc45b364f5fdbcf468
Redis replay protection enabled.

The problem is visible from the deployment's first day, September 8, 2026, so it predates the September 14 app release.

First observed sequence (UTC):
2026-09-08 14:36:23.321 — token_issued.
2026-09-08 15:36:24.331 — token_refreshed.
2026-09-08 15:41:47.738 — refresh_token_reuse_detected.

Comparison client: Claude Code CLI 2.1.273.
The operator confirms that the other account uses Claude Code. That account recorded 51 successful refreshes and no refresh-token reuse detections during the analyzed period, using the same proxy. Repeated reauthentication is not observed with this client.

This is an operational comparison, not a controlled reproduction with identical accounts and workloads.

Potentially related reports:
https://github.com/openai/codex/issues/33540
https://github.com/openai/codex/issues/39054

Begin with the macOS desktop app's MCP OAuth refresh flow and correlate it with the supplied proxy log sequence, especially duplicate submissions and stale refresh-token reuse. Reproduce with one process before investigating concurrent credential holders; done means valid token rotation survives expiry and permanent rejection leads to a clear reauthentication action.