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

[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?

1. 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"]

2. Confirm the server is visible:

codex mcp get tavily
codex mcp list

3. 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.

4. 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.

5. 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:

• Codex desktop can show MCP enabled while thread tool surface omits llm-tldr/serena #16702
• Codex Desktop for Windows does not load local MCP plugin tools #19304
• Codex bug: MCP servers load successfully but their tools aren't exposed to the model #20771
• Codex Desktop does not expose custom MCP tools although codex mcp list sees the server. #25843
• MCP tools disappear or become unsupported in existing long-running threads #26196
• Custom STDIO MCP server enabled and tools/list works, but tools are not exposed in Codex Desktop thread #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