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
- Add a streamable HTTP MCP server that advertises OAuth:
codex mcp add <server-name> --url <streamable-http-mcp-url>
- Authenticate it:
codex mcp login <server-name>
- Complete the browser OAuth flow
- Start a new Codex Desktop thread or restart Codex Desktop
- 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
What version of the Codex App are you using (From “About Codex” dialog)?
Codex Desktop
0.125.0-alpha.3is 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>codex mcp list --jsonshows the server is present and enabledtools/listwith the same bearer token Codex obtained returns the expected tool list from the MCP serverWhat fails:
codex mcp list --jsonreports"auth_status": "unsupported"This makes the server look configured and authenticated, but it is never actually imported into the thread tool registry.
Steps to reproduce
codex mcp add <server-name> --url <streamable-http-mcp-url>codex mcp login <server-name>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 --jsonreturns:[ { "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.tomlcontains:Local thread state shows no dynamic tool entries for the configured MCP server at all. Recent threads only have built-in tools like:
automation_updateread_thread_terminalload_workspace_dependenciesinstall_workspace_dependenciesIn the local SQLite state DB (
~/.codex/state_5.sqlite), thethread_dynamic_toolstable never gets an entry for the configured MCP server in recent threads.Also, the server itself appears healthy:
tools/listreturns401 Unauthorizedtools/listwith the same Codex-issued bearer token succeeds and returns the expected MCP tool listThat 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, butcodex mcp list --jsonstill reports"auth_status": "unsupported"~/.codex/.credentials.jsonon this machine~/.codex/auth.jsondoes not expose a named top-level credential entry for the configured MCP server