Codex App does not import plugin-bundled remote OAuth MCP server tools after codex mcp login until full app restart; new conversation insufficient; codex exec works #30716

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

0.142.4 (latest stable release at time of filing — Codex Desktop)

What subscription do you have?

API key login (Codex Desktop; usage-based OpenAI API billing — not a ChatGPT Plus/Pro/Team subscription)

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

A plugin-bundled remote OAuth MCP server is successfully authenticated, but its tools are never imported into the already-running interactive app, and opening a new conversation in the running app does not help — the tools only appear after a full app restart (quitting and relaunching the process).

What works:

• Plugin installs from a self-hosted marketplace; its .mcp.json declares a remote streamable-HTTP + OAuth server.
• codex mcp login <srv> → Successfully logged in to MCP server '<srv>'.
• codex mcp list shows the server enabled with auth type OAuth (auth_status is not unsupported).
• A fresh codex exec subprocess (new OS process) imports the server's tools (mcp__<srv>.*) and successfully calls them, returning real data.

What fails:

• In the interactive app process that was already running when codex mcp login completed, no mcp__<srv>.* tools are mounted into any thread.
• Starting new conversations within the same running app does not surface the tools (tried many).
• Only fully quitting and relaunching the app makes the tools appear in interactive threads.

Because a fresh codex exec process imports and executes the tools end-to-end with the stored credentials, the server, OAuth, token attachment, tool list, and tool execution are all confirmed working. The gap is specifically that the interactive app does not (re)establish the MCP connection / hot-reload tools after a mid-session codex mcp login, and a new conversation within the same process is not enough to trigger a refresh.

What steps can reproduce the bug?

1. Install a plugin that bundles a remote OAuth MCP server via a self-hosted marketplace (public, reproducible):

   codex plugin marketplace add geoly-ai/codex-plugins
   codex plugin add geoly-mcp@geoly

   The plugin's .mcp.json is:

   {
     "mcpServers": {
       "geoly": {
         "type": "http",
         "url": "https://app.geoly.ai/api/mcp",
         "oauth_resource": "https://app.geoly.ai/api/mcp"
       }
     }
   }

2. With the app already running, authenticate the server:

   codex mcp login geoly        # → "Successfully logged in to MCP server 'geoly'."
   codex mcp list               # → geoly  https://app.geoly.ai/api/mcp  enabled  OAuth

3. In a new conversation in the same running app, ask it to use the server's tools (e.g. $geoly-mcp, or mcp__geoly.list_brands). → No mcp__geoly.* tools are available; only previously-loaded MCP servers and built-ins (e.g. node_repl) are present. Opening more new conversations does not help.
4. Run a fresh subprocess instead:

   codex exec --dangerously-bypass-approvals-and-sandbox "Use the geoly MCP tools. Call list_organizations, then list_brands with org_id."

   → The mcp__geoly.* tools are enumerated and the calls succeed, returning real data.
5. Fully quit and relaunch the app → the mcp__geoly.* tools now appear in interactive threads.

What is the expected behavior?

After a successful codex mcp login <srv>, the running app should (re)connect to the server and import its tools — at minimum a newly opened conversation should pick them up without requiring a full process restart, matching the behavior of a fresh codex exec process (which already works).

Additional information

• Login: OpenAI API key on Codex Desktop (not ChatGPT auth). The related issues below were on ChatGPT-login; here a fresh codex exec on the same machine/login imports and calls the tools, so the gap is the interactive app process lifecycle, not the login type.
• The MCP server is RFC 9728 / streamable-HTTP compliant and reachable: an unauthenticated POST /api/mcp returns 401 with WWW-Authenticate: Bearer resource_metadata="https://app.geoly.ai/.well-known/oauth-protected-resource"; the protected-resource metadata and authorization-server metadata are served and reachable; codex mcp login completes and stores the token.
• The bundled MCP/OAuth client is rmcp 1.8.0 (per codex-rs/Cargo.lock).
• Related issues (this one is distinct):
  • Codex Desktop authenticates OAuth MCP server but never imports tools into threads; auth_status stays unsupported #20009 — similar symptom, but there auth_status stays "unsupported" and restart does not help; here auth_status is fine and a full restart does surface the tools, and codex exec works.
  • Desktop thread can omit configured remote OAuth MCP server from mounted tools with no auth prompt or error #18527 — remote OAuth server omitted from a thread with no auth prompt/error; there the server is not logged in, here it is successfully logged in.
  • MCP OAuth login does not persist across Codex restarts; remote MCP startup incomplete #15122 — MCP OAuth login persistence across restarts.
• Secondary observation: inside codex exec, MCP tool calls were sometimes reported as user cancelled MCP tool call unless --dangerously-bypass-approvals-and-sandbox was passed — the non-interactive approval flow appears to auto-cancel MCP tool calls when no approval is provided.