Codex Desktop does not expose enabled MCP tools in threads, while standalone codex-cli can call the same Tavily MCP config

Open 💬 4 comments Opened Jun 27, 2026 by dionisokan

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

Codex Desktop 26.623.5175.0

What subscription do you have?

Custom provider, details omitted

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Desktop can read my MCP configuration and reports the MCP servers as enabled, but the active Desktop thread does not expose those MCP tools to the model.

The same C:\Users\<user>\.codex\config.toml works from standalone codex-cli 0.142.0: an ephemeral codex exec run successfully calls the Tavily MCP tool. However, Codex Desktop's bundled/internal codex-cli 0.142.3 reports the Tavily MCP tool as unavailable in the same scenario.

This looks like a Desktop/runtime thread tool injection issue, not an MCP server config issue.

Relevant configured MCP server, with secrets redacted:

[mcp_servers.tavily]
type = "stdio"
command = "npx"
args = ["-y", "tavily-mcp@latest"]
env_vars = ["TAVILY_API_KEY"]

[mcp_servers.tavily.tools.tavily_search]
approval_mode = "approve"

Other configured MCP servers include Context7, TinyFish, and Exa. API keys and tokens are omitted.

Both standalone CLI and Desktop internal CLI can read the MCP config:

codex mcp get tavily

returns:

tavily
  enabled: true
  transport: stdio
  command: npx
  args: -y tavily-mcp@latest
  env: TAVILY_API_KEY=*****

The Desktop internal binary also reports the same:

& "$env:LOCALAPPDATA\OpenAI\Codex\bin\aec6b7c6fcdfb66a\codex.exe" mcp get tavily

codex doctor on both binaries reports:

config.toml parse ok
MCP servers: 6
disabled servers: 0
stdio servers: 3
streamable_http servers: 3

But actual thread-level tool availability differs.

Standalone CLI 0.142.0 succeeds:

mcp_tool_call
server: tavily
tool: tavily_search
arguments: {"query":"OpenAI Codex MCP tools not exposed","search_depth":"basic","max_results":1}

It returned a result from GitHub.

Desktop bundled/internal CLI 0.142.3, using the same config and equivalent prompt, returns:

TAVILY_MCP_UNAVAILABLE

No Tavily MCP tool call is emitted.

I also noticed a feature flag difference:

standalone codex-cli 0.142.0:
tool_search_always_defer_mcp_tools   under development  false

Desktop internal codex-cli 0.142.3:
tool_search_always_defer_mcp_tools   removed            true

Trying temporary overrides did not restore Tavily availability in the internal 0.142.3 runtime:

--disable tool_search_always_defer_mcp_tools
--enable tool_search

Both still resulted in TAVILY_MCP_UNAVAILABLE.

What steps can reproduce the bug?

On Windows, configure a stdio MCP server in C:\Users\<user>\.codex\config.toml, for example Tavily:

[mcp_servers.tavily]
type = "stdio"
command = "npx"
args = ["-y", "tavily-mcp@latest"]
env_vars = ["TAVILY_API_KEY"]

Confirm the server is visible:

codex mcp get tavily
codex mcp list

Confirm standalone CLI can actually call the tool:

codex exec --ephemeral --json --skip-git-repo-check --sandbox read-only "Use the Tavily MCP tool to search for 'OpenAI Codex MCP tools not exposed'. If the Tavily tool call succeeds, answer TAVILY_MCP_OK. Do not use shell or built-in web search."

Observed result on standalone codex-cli 0.142.0:

A real mcp_tool_call is emitted for server=tavily, tool=tavily_search.
The final answer is TAVILY_MCP_OK.

Run the equivalent command with the Desktop bundled/internal binary:

& "$env:LOCALAPPDATA\OpenAI\Codex\bin\aec6b7c6fcdfb66a\codex.exe" exec --ephemeral --json --skip-git-repo-check --sandbox read-only "Use the Tavily MCP tool to search for 'OpenAI Codex MCP tools not exposed'. If the Tavily tool call succeeds, answer TAVILY_MCP_OK. Do not use shell or built-in web search."

Observed result on Desktop internal codex-cli 0.142.3:

No Tavily MCP tool call is emitted.
The final answer is TAVILY_MCP_UNAVAILABLE.

In Codex Desktop threads, the assistant also cannot call Tavily even though mcp list/get shows it as enabled.

What is the expected behavior?

If codex mcp list/get and codex doctor show an MCP server as enabled and configured, Codex Desktop threads should expose that server's tools to the model, or show a clear diagnostic explaining why they were not injected.

The same MCP config should not work in standalone CLI 0.142.0 but fail in Desktop/internal 0.142.3 without an explicit error.

Additional information

This appears similar to existing reports where MCP servers are enabled and protocol-visible, but tools are not injected into Desktop threads, including issues such as:

#16702
#19304
#20771
#25843
#26196
#26659

This report adds a Windows Desktop 26.623.5175.0 case with a same-machine comparison between:

standalone codex-cli 0.142.0, which successfully calls Tavily MCP
Desktop bundled/internal codex-cli 0.142.3, which does not expose Tavily MCP tools

View original on GitHub ↗

4 Comments

DreamingBeast · 1 month ago

Same issue with re-mcp-ida, /mcp shows the server is active, but model have no access to the tools, however model can access the tools using JSON-RPC wrapper just fine, but not via codex itself

colevr1 · 1 month ago

same issue with all MCP

SamuelMiller · 1 month ago

Same ISSUE with all added MCPs

Bug: Enabled MCP server is not exposed because Codex Desktop chat PATH omits Windows/Node paths

Summary

On Windows 11, an enabled MCP server appears in Codex Desktop MCP settings and config.toml, but its tools are not available in chat. The chat process appears to inherit a restricted PATH, so MCP startup commands that rely on cmd, npx, or node fail.

Environment

OS: Windows 11
App: Codex Desktop
Config: C:\Users\Computer\.codex\config.toml

MCP config

[mcp_servers.firecrawl-mcp]
command = "cmd"
args = ["/c", "npx", "-y", "firecrawl-mcp"]
enabled = true

[mcp_servers.firecrawl-mcp.env]
FIRECRAWL_API_KEY = "<redacted>"

Observed behavior

Firecrawl MCP is configured and enabled.
The chat does not expose Firecrawl tools.
Searching available tools for firecrawl returns no matches.

Diagnostics

The chat process PATH did not include normal Windows or Node locations such as:

C:\Windows\System32
C:\Program Files\nodejs

As a result:

cmd /c npx -y firecrawl-mcp --help

fails because cmd is not found.

Using the full path to cmd.exe:

& 'C:\Windows\System32\cmd.exe' /c npx -y firecrawl-mcp --help

then fails because npx is not found.

npx.cmd and node.exe are installed at:

C:\Program Files\nodejs\npx.cmd
C:\Program Files\nodejs\node.exe

Temporarily prepending Node to PATH makes the Firecrawl launch command work:

$env:Path = 'C:\Program Files\nodejs;' + $env:Path
& 'C:\Program Files\nodejs\npx.cmd' -y firecrawl-mcp --help

Expected behavior

Codex Desktop should launch enabled MCP servers with a Windows environment that can resolve standard commands, including cmd, npx, and node, or it should clearly report MCP startup failures in chat/settings.

Actual behavior

The MCP server is shown as enabled, but its tools are silently unavailable in chat because the startup command cannot resolve through the inherited PATH.

hoggatt · 27 days ago

Additional reproduction: VS Code on macOS, remote Streamable HTTP server never receives `POST initialize`

I can reproduce the same thread-level MCP omission with the stable Codex VS Code extension and a remote Streamable HTTP MCP server. This case does not use Node, npx, or a stdio launcher, so it rules out the Windows/PATH explanation from the preceding comment.

Environment

Codex VS Code extension: 26.727.40816 (stable gallery channel)
Bundled CLI: codex-cli 0.146.0-alpha.9.2
VS Code: 1.131.0
macOS 26.5.2, Apple Silicon (arm64)
MCP transport: remote Streamable HTTP over HTTPS
Authentication: static Authorization: Bearer <redacted> HTTP header

Sanitized configuration:

[mcp_servers.example-remote]
enabled = true
url = "https://<private-host>/example/mcp"
startup_timeout_sec = 20

[mcp_servers.example-remote.http_headers]
Authorization = "Bearer <redacted>"

Reproduction

Add the remote Streamable HTTP server in Codex Settings.
Confirm it is enabled.
Completely quit and restart VS Code.
Create a new Codex chat/thread.
Ask Codex to list or read a resource from the configured server.

Actual behavior

Codex returns immediately:

MCP server 'example-remote' was not ready for this step

The same error is returned by both resources/list and resources/templates/list.

The key server-side observation is that Codex sends no MCP request at all during thread creation or the failed resource call:

No POST initialize
No other POST
No GET
No request reaches nginx at the time of the chat failure

Codex Settings does send an authenticated HEAD health probe, which receives 204. A direct request from the same Mac using the same configured header also receives 204 in under one second. Manual MCP POST requests receive 200, and VS Code Copilot successfully initializes and uses the same endpoint. This rules out DNS, TLS, routing, nginx, authentication, timeout, and MCP backend availability.

The Codex extension log shows the fresh app-server starting but no initialization attempt for either configured remote MCP server. The structured Codex trace repeatedly resolves only the bundled computer-use server for the thread; the configured Streamable HTTP servers never enter the thread's MCP connection manager.

Configuration diagnostics are healthy:

codex mcp get example-remote
  enabled: true
  transport: streamable_http
  url: https://<private-host>/example/mcp
  http_headers: Authorization=*****
  startup_timeout_sec: 20

codex doctor --json reports:

config.load: ok
mcp.config: ok
configured servers: 2
disabled servers: 0
streamable_http servers: 2
network provider reachability: ok
network websocket reachability: ok

The bundled feature state matches the suspicious state reported in the original issue:

tool_search                          removed            false
tool_search_always_defer_mcp_tools   removed            true
tool_suggest                         stable             true

Both of these command-line overrides are ignored by the bundled binary; the feature state remains unchanged:

--disable tool_search_always_defer_mcp_tools
--enable tool_search

Current upstream source appears to define tool_search_always_defer_mcp_tools as under development and default-disabled, unlike the bundled extension binary's removed/enabled state:

https://github.com/openai/codex/blob/main/codex-rs/features/src/lib.rs

Expected behavior

An enabled and valid Streamable HTTP MCP server should be initialized when a fresh VS Code Codex thread starts or when the thread requests its resources/tools. Codex should send POST initialize and expose the server's capabilities. If initialization is intentionally suppressed, the UI should report the actual policy/discovery reason rather than the misleading not ready for this step error.

All endpoint names, credentials, client IPs, and local user paths in this comment are anonymized.

Codex Desktop does not expose enabled MCP tools in threads, while standalone codex-cli can call the same Tavily MCP config

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

4 Comments

Same ISSUE with all added MCPs

Bug: Enabled MCP server is not exposed because Codex Desktop chat PATH omits Windows/Node paths

Summary

Environment

MCP config

Observed behavior

Diagnostics

Expected behavior

Actual behavior

Additional reproduction: VS Code on macOS, remote Streamable HTTP server never receives POST initialize

Environment

Reproduction

Actual behavior

Expected behavior

Additional reproduction: VS Code on macOS, remote Streamable HTTP server never receives `POST initialize`