Desktop thread can omit configured remote OAuth MCP server from mounted tools with no auth prompt or error

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

0.122.0-alpha.1

What subscription do you have?

Pro

What platform is your computer?

macOS 15.7.4 (24G517), arm64

What issue are you seeing?

A configured and enabled remote OAuth MCP server can be present in local Codex config, reachable on the network, and still be completely absent from the mounted tool catalog for a new thread.

In my case, the server is Bridge Town:

[mcp_servers.bridge_town]
enabled = true
url = "https://api.bridgetown.builders/mcp"

and it is also present in the local factory MCP config.

However, in a fresh Codex desktop thread, Bridge Town is not exposed as a callable tool at all. There is also no OAuth prompt, no auth-needed error, and no tool-mount error surfaced in the thread.

So from the user side this looks like: “MCP is enabled, server is up, but Codex silently does not mount it into the thread.”

What steps can reproduce the bug?

1. Configure a remote OAuth MCP server in local Codex config, for example:

[mcp_servers.bridge_town]
enabled = true
url = "https://api.bridgetown.builders/mcp"

1. Start a fresh Codex desktop thread in a trusted workspace.
2. Ask Codex to use that MCP in the thread.
3. Observe that the MCP tool namespace is not available in the thread at all.
4. Observe that there is no OAuth login prompt and no explicit auth error.
5. Independently verify the endpoint is reachable and advertising OAuth protection:

curl -I https://api.bridgetown.builders/mcp
HTTP/2 401
www-authenticate: Bearer resource_metadata="https://api.bridgetown.builders/.well-known/oauth-protected-resource"

What is the expected behavior?

One of these should happen:

1. Codex mounts the MCP tools into the thread and lets me authenticate.
2. Codex surfaces a clear “auth required / login needed” state for that server.
3. Codex surfaces a clear tool-mount failure / MCP initialization error.

What should not happen is silent omission of the configured MCP from the thread’s callable tools.

Actual behavior

The thread only gets the built-in tools and the configured MCP never appears as a callable tool namespace.

In the failing thread, the mounted dynamic tools were only:

• automation_update
• read_thread_terminal
• load_workspace_dependencies
• install_workspace_dependencies

No Bridge Town or other MCP tool namespace was mounted.

Additional information

• The relevant thread id on my machine was 019da3b9-640f-7153-ba9c-2b34b0a1db91.
• Local config definitely contains the enabled server.
• The Bridge Town endpoint was reachable and returned an OAuth-protected 401, so this does not look like a basic network outage.
• The failure mode is specifically that the server is not exposed into the thread as tools, and the app gives no actionable reason.

This feels closely related to existing MCP exposure issues, but the important distinction here is:

• remote HTTP MCP
• OAuth-protected endpoint
• server reachable
• still not mounted into the thread tool catalog
• no auth handoff / prompt / explicit error

If this is expected behavior, Codex should at least surface that clearly in the thread or MCP status UI.