codex - 💡(How to fix) Fix Codex Desktop authenticates OAuth MCP server but never imports tools into threads; auth_status stays unsupported [1 comments, 2 participants]

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

Codex Desktop 0.125.0-alpha.3 is shown in local session metadata as the active CLI/app runtime.

What subscription do you have?

Unknown from the app logs on this machine.

What platform is your computer?

macOS (Darwin, Apple Silicon). The workspace is local.

What issue are you seeing?

Codex Desktop successfully adds and authenticates a streamable HTTP MCP server, but never surfaces that server's tools in any thread.

What works:

• codex mcp add <server-name> --url <streamable-http-mcp-url>
• codex mcp login <server-name>
• OAuth completes successfully multiple times
• codex mcp list --json shows the server is present and enabled
• Manually calling tools/list with the same bearer token Codex obtained returns the expected tool list from the MCP server

What fails:

• codex mcp list --json reports "auth_status": "unsupported"
• Codex Desktop threads never receive any dynamic tool entries for the configured MCP server
• Restarting Codex Desktop does not help
• Removing the server, re-adding it, and re-authing from scratch does not help

This makes the server look configured and authenticated, but it is never actually imported into the thread tool registry.

Steps to reproduce

1. Add a streamable HTTP MCP server that advertises OAuth:
   • codex mcp add <server-name> --url <streamable-http-mcp-url>
2. Authenticate it:
   • codex mcp login <server-name>
3. Complete the browser OAuth flow
4. Start a new Codex Desktop thread or restart Codex Desktop
5. Ask the thread whether the MCP server's tools are available

Expected behavior

After successful OAuth, Codex Desktop should import the MCP server's tools into new threads.

Actual behavior

The server remains visible in MCP config, but no tools from that MCP server are exposed in threads.

Evidence

codex mcp list --json returns:

[
  {
    "name": "<server-name>",
    "enabled": true,
    "disabled_reason": null,
    "transport": {
      "type": "streamable_http",
      "url": "<streamable-http-mcp-url>",
      "bearer_token_env_var": null,
      "http_headers": null,
      "env_http_headers": null
    },
    "startup_timeout_sec": null,
    "tool_timeout_sec": null,
    "auth_status": "unsupported"
  }
]

~/.codex/config.toml contains:

[mcp_servers.<server-name>]
url = "<streamable-http-mcp-url>"

Local thread state shows no dynamic tool entries for the configured MCP server at all. Recent threads only have built-in tools like:

• automation_update
• read_thread_terminal
• load_workspace_dependencies
• install_workspace_dependencies

In the local SQLite state DB (~/.codex/state_5.sqlite), the thread_dynamic_tools table never gets an entry for the configured MCP server in recent threads.

Also, the server itself appears healthy:

• Unauthenticated tools/list returns 401 Unauthorized
• The server advertises OAuth metadata correctly
• Manual tools/list with the same Codex-issued bearer token succeeds and returns the expected MCP tool list

That suggests the server is not the problem; the issue appears to be in Codex Desktop/CLI auth classification or MCP tool import after login.

Additional notes

• codex mcp login <server-name> succeeds repeatedly, but codex mcp list --json still reports "auth_status": "unsupported"
• There is no legacy ~/.codex/.credentials.json on this machine
• The visible ~/.codex/auth.json does not expose a named top-level credential entry for the configured MCP server