MCP tools configured globally are inconsistently exposed to new sessions, and OAuth failures are not automatically recovered

Summary

I have a remote MCP map service configured globally in Codex. The service is registered and usable, but new Codex conversations do not reliably behave as if the MCP tools are available. In some sessions, the agent appears unaware of the registered tool surface even though the MCP server is already configured globally.

A second issue appears in the same workflow: when MCP OAuth authentication has expired or failed, Codex treats the tool call as failed and often gives up instead of recovering authentication and resuming the original tool invocation.

From a user perspective, these two behaviors make globally configured MCP tools feel nondeterministic across sessions.

Observed behavior

1. Global MCP registration is not consistently reflected in new conversations

1. Configure an MCP server globally in Codex config.
2. Verify the server is registered/enabled and its tools are normally usable.
3. Start a new Codex conversation.
4. Ask Codex to perform a task that should use the MCP tool.
5. In some new conversations, Codex behaves as if the tool is unavailable or not registered in its current context.

The server configuration has not changed between conversations.

2. OAuth failure becomes a terminal tool failure instead of a recoverable state

1. Use a globally configured remote MCP server that requires OAuth.
2. Let the access token expire, or otherwise enter a state where reauthentication is required.
3. Ask Codex to perform a task using that MCP server.
4. The MCP invocation fails due to authentication.
5. Codex abandons the tool path instead of attempting to refresh/re-authenticate and resume the original request.

In practice this can require manual login and then repeating the user request, starting a new conversation, or restarting Codex before the MCP tool is usable again.

Expected behavior

Globally enabled MCP servers should have a deterministic lifecycle across conversations:

• Every new conversation should consistently receive the enabled MCP tool surface from the global configuration.
• If an OAuth access token can be refreshed non-interactively, Codex should refresh it automatically and retry the failed MCP request.
• If interactive authorization is required, Codex should initiate or surface the login flow instead of treating authentication failure as a normal terminal tool error.
• After successful authentication, Codex should refresh the MCP tool inventory/state if necessary and automatically retry or resume the original tool call.
• The user should not need to repeat the original request, create a new conversation, or restart Codex merely to make an already configured MCP server usable again.

A desirable user-visible flow would be:

user request
  -> MCP tool selected
  -> auth failure detected
  -> refresh token if possible
  -> otherwise request interactive OAuth
  -> authentication succeeds
  -> refresh MCP capability/tool state
  -> retry the original tool call
  -> continue the original task

Why this matters

Global MCP configuration implies that the capability is part of the Codex environment, not something the user should need to re-explain or rediscover in each conversation.

Similarly, OAuth expiration is a runtime state transition, not a change in user intent. Treating it as a terminal agent/tool failure leaks infrastructure state into the conversation and makes otherwise stable MCP integrations unreliable.

This is especially noticeable for services intended to be used as persistent infrastructure, such as map/search/internal-platform MCP servers.

Related issues

There are existing reports covering adjacent parts of this lifecycle:

• #19425 — MCP server discovered via tools/list, but tools not exposed to Desktop threads.
• #37567 — OAuth succeeds but tools are not cached/exposed after startup in a regression case.
• #41133 — MCP OAuth refresh-token lifecycle/persistence problem during shutdown.

This issue is specifically about the end-to-end user-visible lifecycle across global configuration -> new session tool exposure -> OAuth recovery -> automatic retry/resume of the original tool call.

Suggested acceptance criteria

A regression/integration test could cover the following:

1. Register a remote OAuth MCP server globally.
2. Open multiple new conversations and verify its tools are exposed consistently in each one.
3. Expire the access token while keeping refresh credentials valid.
4. Invoke a tool and verify Codex refreshes authentication and retries automatically.
5. Force a state requiring interactive OAuth.
6. Complete authentication and verify the original MCP call resumes without requiring the user to repeat the request or restart Codex.

No implementation files or tests are named. Start by tracing global MCP configuration into new-session tool exposure, then follow the OAuth failure path through authentication and retry handling. Done means repeated new conversations consistently expose configured tools and expired or interactive OAuth recovers and resumes the original tool call without repetition or restart.