›_ Codex Issues
Codex Issues / #10499

Desktop app shows MCP servers in Settings, but /mcp in chat shows none (tools unusable); TUI works

Open 💬 7 comments Opened Feb 3, 2026 by amtiYo

What version of Codex is running?

0.94.0

What subscription do you have?

Plus

Which model were you using?

gpt-5.2-codex

What platform is your computer?

Darwin 25.2.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

Terminal.app 2.15

What issue are you seeing?

<img width="300" alt="Settings screenshot" src="https://github.com/user-attachments/assets/3233e5b8-5c51-417e-a8e0-9ad733325603" />

In Codex Desktop, MCP servers appear in Settings → MCP Servers, but inside the Desktop chat the /mcp command shows only global MCPs, and the model cannot use the project-scoped tools.
In the TUI (codex CLI), /mcp lists all project MCPs correctly and tools work.

<img width="300" alt="MCP list screenshot" src="https://github.com/user-attachments/assets/458e183d-c288-4b6c-9adb-e63dad194ebd" />

What steps can reproduce the bug?

Create [config.toml](app://-/index.html#) in the repo with several [mcp_servers.*](app://-/index.html#).
Trust the project in CLI (Desktop has no trust UI) and restart Desktop.
Open Settings → MCP Servers (servers appear).
In Desktop chat, run /mcp — only global MCPs are listed (project MCPs missing).
In terminal, cd to the project, run codex, then /mcp — all project MCPs are listed and usable.

What is the expected behavior?

Desktop chat /mcp should list the same MCP servers shown in Settings, and the model should be able to use them.

Additional information

_No response_

View original on GitHub ↗

7 Comments

gapurov · 5 months ago

In addition to that, local mcps, which are defined on the project level are not working in the Desktop App, although fully functional in the TUI.

skoch13 · 4 months ago

I stumbled upon the similar issue, but when opening Codex App from terminal via codex app environment is loaded properly

jlrickert · 4 months ago

I can reproduce a closely related desktop MCP failure locally with a third-party local stdio MCP server.

In my case the server command is tap mcp from https://github.com/jlrickert/tapper, but I do not think the server implementation is the issue.

What I see on March 18, 2026:

  • The MCP server command itself is valid and starts cleanly from the shell.
  • The same stdio server works outside the Codex desktop settings save path.
  • After saving or editing the server in Codex desktop settings, the desktop log records config/batchWrite followed by configValidationError: invalid type: null, expected any valid TOML value.
  • After that, the server may still appear in Settings but fail to attach in desktop chat.

This looks like a desktop settings serialization bug rather than an MCP server bug.

Local repro:

  1. Add a stdio MCP server with command = "tap" and args = ["mcp"]
  2. Save or edit it in Codex desktop settings
  3. Restart Codex desktop
  4. Open a new chat/session and check MCP availability

Expected:

  • the config saves cleanly
  • the server attaches in desktop chat

Actual:

  • desktop logs configValidationError
  • the server does not reliably attach, even though the server command itself remains valid

Current hypothesis: the settings UI/save path is emitting optional unset values in a way that becomes null during config write, and the TOML validator rejects that write.

stewones · 3 months ago

same issue here

Trunksome · 2 months ago

I’m seeing a similar issue in Codex Desktop.

Environment:

  • macOS
  • Codex CLI 0.130.0-alpha.5
  • Project has MCPs configured in .codex/config.toml
  • Project is trusted

From the repo root, codex mcp list correctly shows the project MCPs, including Sentry, Grafana, kubectl-readonly, and Postgres read-only. These also appear in Codex Desktop Settings.

But inside a Desktop thread, /mcp only shows codex_apps and does not expose the project MCP tools to the model. The agent cannot call any of the expected project tools (mcp__Sentry__*, Grafana, kubectl, Postgres, etc.).

This makes MCP-backed workflows basically unusable in Desktop: the config is visible, but the actual thread/tool surface does not receive the tools, so project skills that rely on MCPs fail or have to fall back to ad hoc shell/API work.

The key mismatch is:

  • codex mcp list sees the MCPs
  • Desktop Settings sees the MCPs
  • /mcp in the thread does not show them
  • the model does not receive the tools

It would be very helpful to have diagnostics that distinguish “configured”, “server initialized”, “tools discovered”, and “tools injected into this thread”. Right now the UI suggests the MCPs exist, but the session behaves as if they do not.

yunusemregul · 4 days ago

I am seeing the same Desktop-side discrepancy on a newer version:

  • Codex Desktop: 26.707.72221
  • Desktop-bundled Codex CLI/app-server: 0.144.2
  • macOS
  • two custom global Streamable HTTP MCP servers

Both servers appear enabled through codex mcp list, including when using the CLI bundled inside Codex.app. Both successfully complete MCP initialization and return valid tool definitions from tools/list. Their tools are callable through a direct MCP client.

Despite that, a fresh Desktop thread exposes no mcp__<server>__... namespace or callable tools. Restarting Desktop and opening a new thread does not resolve it.

I added the detailed reproduction to #19425. Because these servers are tool-oriented and do not advertise resources, #14242 may describe a contributing discovery path. #19649 also documents the same registered-but-not-injected regression family.

This confirms that the Desktop Settings/configuration inventory and the actual per-thread callable tool registry can still diverge on app-server 0.144.2.

yunusemregul · 4 days ago

Follow-up: I found a concrete cause for the Desktop/thread discrepancy and prepared a tested fix.

When code_mode_only is active, discovered MCP tools are deferred to tool_search. However, tool_search itself had normal exposure and was filtered off the direct model tool surface. This explains how Desktop/config inventory and successful tools/list can coexist with a thread that has neither direct mcp__... tools nor a search bridge.

The patch keeps tool_search top-level as DirectModelOnly, leaves MCP tools deferred, and tests the complete Responses Lite search -> namespace -> MCP call flow.

The review PR is in the fork because the upstream repository uses invitation-only external contributions and rejected direct PR creation. The branch is ready to submit unchanged if a maintainer invites it.