Codex MCP OAuth sessions expire and require application restart

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #31385

Powered by Codex Action

Analysis (community)

Thanks for tracking this — attempting a residual-focused analysis aligned with docs/contributing.md (invitation-only: analysis in-thread, no unsolicited PR).

• Issue under review: #32590 — Codex MCP OAuth sessions expire and require application restart
• Theme / radar cluster: MCP OAuth refresh / reauth loop (mcp-auth)
• Reporter posture: static + local evidence where available; not claiming a maintainer invite.

Observed (from issue + public residual signal)

What version of the Codex App are you using (From “About Codex” dialog)? 26.707.51957 ### What subscription do you have? Pro ### What platform is your computer? MaDarwin 25.5.0 arm64 arm ### What issue are you seeing? I use the Notion MCP server extensively for work. Recently, its OAuth/MCP session appears to expire or become invalid after approximately one hour, whereas it previously remained usable significantly longer. The first failure observed was: `Transport send error: ... StreamableH

Root-cause hypothesis

OAuth refresh / mid-session tool drop / forced re-login appears as a lifecycle bug across app-server and CLI: token refresh soft-fails, MCP init hangs, tools vanish without clear recovery.

High-level fix outline (not a PR)

• Make refresh failures explicit + recoverable without full restart.
• Ensure singleflight setup cannot block all tools indefinitely.
• Fail-first: mock OAuth server with expiring tokens + refresh success/fail cases.

Related

#32590, #17265 family — join existing analysis, do not refile umbrella.

Questions for maintainers

1. Is the intended long-term policy documented for this area (especially sandbox gitdir / log TRACE defaults)?
2. Preferred residual anchor issue if several open threads describe the same mechanism?
3. If the high-level outline above is roughly aligned, would an invited PR with failing-first tests be welcome later — or is an internal fix preferred?

Happy to refine with more measurements or code pointers. No unsolicited PR from me.

Analysis (community)

Residual analysis for #32590 (MCP OAuth sessions expire; restart required) — invitation-only. Distinct from broader OAuth callback/iss threads: focus is in-session refresh/reconnect after expiry. No unsolicited PR.

Deterministic evidence (code + local TRACE)

Code (5dd992acd3):

• Token status enum in codex-rs/rmcp-client/src/oauth.rs:
• StoredOAuthTokenStatus::Usable | AuthorizationRequired | Missing (≈L104–L126)
• token_needs_refresh / .refresh_token() path (≈L164–L166)
• refresh helpers: oauth.rs modules refresh_lock, refresh_transaction
• Auth status mapping in codex-rs/rmcp-client/src/auth_status.rs:
• Usable → McpAuthState::OAuth
• AuthorizationRequired → forces re-auth UX
• Missing continues into discovery (supports_oauth_login / streamable HTTP OAuth discovery)
• Failure to detect OAuth support logs at discovery time (auth_status.rs ≈L197 message pattern for MCP server name/url).

Runtime (codex-cli 0.146.0-alpha.6):

• Local TRACE histogram includes codex_mcp::connection_manager = 1745 rows — MCP lifecycle is actively chatty under real sessions, consistent with reconnect/init churn when auth state flips.

Root-cause hypothesis

When refresh soft-fails or returns AuthorizationRequired mid-session, tool surfaces disappear until full process restart re-runs discovery + token load. Missing: user-visible refresh failure event + singleflight-safe in-session reconnect that does not block the entire tool registry indefinitely.

High-level fix outline (not a PR)

1. Emit explicit MCP auth-refresh failure events; offer “Re-authenticate” without restart.
2. Bound MCP init/reconnect with timeouts; never leave tools permanently empty on one bad refresh.
3. Document store modes (OAuthCredentialsStoreMode) and when keyring vs file loses tokens across upgrades.
4. Fail-first: mock OAuth with short-lived tokens; assert refresh success path and AuthorizationRequired recovery path.

Questions for maintainers

1. Is #32590 the preferred residual anchor vs the broader MCP OAuth family?
2. Who owns reconnect UX — TUI, app-server, or rmcp-client?
3. Would an invited PR for reconnect + tests be welcome?

No unsolicited PR from me.

Additional data from Codex CLI 0.147.0 on macOS arm64 against a Streamable HTTP OAuth MCP server.

I used the app-server protocol as a deterministic probe: initialize, start an ephemeral thread, call mcpServerStatus/list with that thread ID, then invoke one read-only MCP tool directly through mcpServer/tool/call.

With a 5-second access-token TTL, three fresh processes each contacted the provider, completed the refresh transaction, loaded the tool catalog, and completed the direct tool call (3/3). After restoring the normal 1-hour TTL, the first process refreshed and succeeded; a second process reused the persisted credential and also succeeded (2/2).

I therefore cannot reproduce post-refresh catalog loss after a clean reauthorization on 0.147.0. An earlier stale state did show OAuth in codex mcp list while the server exposed zero tools; repeating the MCP login repaired it. This suggests codex mcp list confirms that a credential is stored, but is not itself proof that the current process loaded a usable catalog.

One possible regression-coverage improvement: the current streamable_http_oauth_startup test exercises refresh through initialize, but does not appear to assert a subsequent tools/list result or propagation into the client tool catalog. Extending it through tools/list could guard the symptom reported here.

No credentials, endpoint names, or workspace identifiers are included in this report.

Correction and follow-up to my previous comment: that result used mcpServerStatus/list plus direct tool dispatch, which can succeed through a temporary connection even when the active thread did not expose the MCP tool to the model. Please treat the earlier non-reproduction conclusion as superseded.

I revised the probe to start a fresh ephemeral thread and run a real model turn before any status or direct-call diagnostics. The process used a read-only OAuth grant and an effective MCP tool allowlist containing only one read-only tool; apps, web search, collaboration, and image tools were disabled. The oracle requires a turn-scoped, item-ID-correlated model MCP call with the exact requested argument.

On Codex CLI 0.147.0 with a 5-second access-token TTL, three fresh processes produced the same result:

• provider refresh contacted and transaction completed: 3/3
• model-visible MCP tool call observed: 0/3
• post-turn status connection listed the tool: 3/3
• post-turn direct read-only tool call succeeded: 3/3

This reproduces the catalog-loss symptom after successful refresh while showing that transport, authorization, tools/list through the temporary status connection, and literal direct dispatch are healthy. The failure is specifically active-thread model catalog hydration.

No credentials, endpoint names, workspace identifiers, or raw tool results are included. The suggested regression test should therefore assert that the refreshed server tool reaches the active thread model tool registry, not only that initialize or an independent tools/list call succeeds.

Related report from current ChatGPT/Codex Desktop on macOS (Desktop 26.803.41515, bundled codex-cli 0.147.0-alpha.6.5).\n\nThis appears to be the same connector/tool-exposure lifecycle class, but affects built-in app connectors:\n\n- HubSpot and Google Drive both complete OAuth, then the desktop UI reverts to “Connect”.\n- Fresh connector links appear in the local app-tools cache, but neither connector’s tools become available in the desktop session.\n- Both connectors work in ChatGPT web on the same account.\n- Moving aside ~/.codex/cache/codex_apps_tools and ~/.codex/cache/codex_app_directory and restarting did not help.\n- Other connectors, including Airtable, work in the same desktop session.\n\nSo the connection/auth handshake appears to complete, but the desktop active-thread tool registry is not hydrated. This seems closely related to the active-thread catalog-loss behavior described here, and to Google Drive’s separate exposure issue in #25854.\n\nCould maintainers confirm whether built-in Codex Apps connectors are covered by this issue, or whether this should be tracked separately?

Additional deterministic reproduction on current ChatGPT/Codex Desktop against a private remote Streamable HTTP OAuth MCP server.

No endpoint, organization, workspace, tenant, user, client, credential, token/family identifier, raw log, transcript, tool payload, or screenshot is included here.

Environment

• ChatGPT/Codex Desktop: 26.810.52044 (build 6662)
• Bundled Codex CLI: 0.148.0-alpha.9
• PATH Codex CLI: 0.145.0
• macOS: 27.0 (26A5388g)
• Transport: Streamable HTTP
• Authentication: OAuth
• Access-token lifetime: 1 hour

Reproduction

1. Complete one manual OAuth reconnect.
2. Immediately start/use an existing desktop thread with the MCP mounted.
3. Invoke one read-only MCP tool.

• Result: success; no additional user authentication is requested.

1. Leave the desktop app and connector untouched across several access-token lifetimes.
2. Observe the OAuth provider/server state independently.

• Refresh transactions complete successfully at approximately hourly intervals.
• Multiple credential holders advance.
• The refresh family remains healthy, unrevoked, and below its recovery/capacity limits.

1. Return to the active desktop thread after expiry.

• Desktop shows: “Authentication expired. Reconnect to keep using this MCP server.”
• The MCP tool namespace is absent from the model-visible inventory.
• An attempted model tool call fails before reaching the MCP transport with the equivalent of:

tools.mcp__<redacted>__<redacted_tool> is not a function

1. Quit and relaunch the desktop app without reconnecting.

• The Reconnect popup remains.
• The MCP tool namespace is still absent.
• No MCP request is attempted from the affected thread.

1. Independently verify the MCP endpoint/catalog.

• Initialization and tool discovery remain healthy and return the expected catalog.

Key distinction

This is not a provider-side refresh rejection, refresh-token expiry, family revocation, or catalog outage. Provider-side refresh succeeds repeatedly while the desktop process transitions to Authentication expired and drops the model-visible tool namespace.

This corroborates the active-thread catalog-hydration diagnosis in the previous comments: transport/auth state can be healthy while refreshed MCP tools never reach—or no longer remain in—the active thread model registry.

Expected behavior

After a successful OAuth refresh, Codex should persist/adopt the refreshed credential and keep or rehydrate the MCP tools in the active thread. On process restart it should reload the valid refreshed credential and catalog without requiring another manual Reconnect.