›_ Codex Issues
Codex Issues / #21654

Codex App shows MCP servers enabled, but current session only receives a subset of MCP tools

Open 💬 6 comments Opened May 8, 2026 by kilokahn
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

Version 26.506.21252 (2575)

What subscription do you have?

Enterprise

What platform is your computer?

Darwin 25.4.0 arm64 arm

What issue are you seeing?

Codex App Settings shows multiple MCP servers enabled/active in the MCP Servers modal, and codex mcp list also reports those servers as enabled. However, the active chat session only receives callable tools from a subset of those enabled servers.

In one observed session:

  • Settings showed four MCP servers enabled.
  • codex mcp list also showed those same four servers as enabled.
  • The active chat session exposed tools from only one of those servers.
  • The other enabled MCP servers did not appear as callable tool namespaces in the session.

This creates a mismatch between the Settings UI and the actual session tool surface. The UI indicates that MCP servers are enabled, but the user cannot tell whether each server's tools were discovered, imported, and attached to the current chat session.

All MCP server names are intentionally redacted here because they are private/internal. The important behavior is that the app-level Settings state and the per-session callable tool state disagree.

What steps can reproduce the bug?

  1. Configure multiple MCP servers in Codex App.
  2. Confirm that the MCP Servers Settings modal shows the servers enabled/active.
  3. Run codex mcp list and confirm those servers are reported as enabled.
  4. Start or resume a Codex App chat session.
  5. Ask the assistant whether it can see/use the configured MCP tools, or attempt a task that requires one of the enabled MCP servers.
  6. Observe that only a subset of the enabled MCP servers are available as callable tools in the session.

Expected diagnostic data that would help reproduce/debug:

Enabled MCP servers in Settings: 4
Enabled MCP servers in codex mcp list: 4
MCP servers with tools exposed to active session: 1

The current UI does not reveal whether the unavailable servers failed startup, handshake, tools/list, schema import, auth/env setup, or session attachment.

What is the expected behavior?

If Codex App Settings shows an MCP server as enabled/active, the UI should also make clear whether that server's tools are actually available to the current chat session.

If a server is enabled but not usable by the current session, Codex should show the reason instead of leaving the user to infer it from the assistant's behavior.

Ideally the MCP Servers modal, or a session diagnostics panel, would expose per-server readiness like:

Enabled: yes
Process reachable: yes/no
Tools discovered: <count>
Resources discovered: <count>
Attached to current session: yes/no
Last tools/list result: success/error/timeout
Last error: <message, if any>

A compact version would also help:

server-a
Enabled: yes
Session tools: unavailable
Reason: tools/list timed out / schema import failed / not attached to current session

Additional information

This is related to MCP visibility/session mismatch reports, but the ask here is specifically for product diagnostics:

  • show the difference between configured/enabled MCP servers and tools attached to the current session
  • surface the last MCP discovery/import error in the UI
  • make the Settings modal a reliable source of truth for session usability, not just configuration state

Closest public report found:

Related MCP tool-discovery diagnostic report:

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #20009
  • #20771
  • #20707
  • #20539

Powered by Codex Action

kilokahn · 3 months ago

While https://github.com/openai/codex/issues/19425 seems like the closest match, a feature to do the session diagnostic panel is not requested in those.

AdamGustavsson · 2 months ago

Codex is much worse than Cursor or github copilot when it comes to feedback of failing MCP servers.
Its important as getting an MCP to work is often a bit of trial-and-error. In Codex you get NO FEEDBACK at all.

NewSNode · 2 months ago

直接 HTTP 验证 MCP 后端 100% 健康

$ curl -X POST https://developers.openai.com/mcp -H "Authorization: Bearer $OPENAI_API_KEY" ...
→ STATUS 200, server=openai-docs-mcp v1.0.0
→ tools/list 返回 5 个 tool schema

但 app 侧全部 unsupported call

mcp__openaiDeveloperDocs__list_api_endpoints → "unsupported call"
mcp__openaiDeveloperDocs__search_openai_docs → "unsupported call"
mcp__fetch__fetch → "unsupported call"
mcp__node_repl__js → "unsupported call"
list_mcp_resources → []

环境对照

codex --version = codex-cli 0.142.0-alpha.6 (≥ 0.120.0 回归区)
Codex App 路径 = C:\Program Files\WindowsApps\OpenAI.Codex_26.616.5445.0_...
codex mcp list = 3 enabled
node_repl.exe 进程 = 3 个在跑(PID 584/21320/41684)
~/.codex/config.toml = 无 enabled_tools 过滤

only-dev-ops · 1 month ago

The issue is their use_responses_lite: false. Add a model_catalog_json to turn that BS off.

TeaShaman-cyber · 1 month ago

Additional current-build datapoint (2026-07-22):\n\n- Codex Desktop Windows package: 26.715.9757.0\n- codex-cli: 0.144.5\n- Host: Windows 11, app-server running in Ubuntu 24.04 WSL\n- 8 MCP servers are configured; the runtime log reports 5 available and 3 unavailable.\n- For the missing servers, logs repeatedly contain: MCP server tools unavailable while building tool list ... has_cached_tools=false startup_complete=true\n- codex mcp list still reports the servers enabled.\n- An external JSON-RPC stdio probe against one missing local server successfully completes initialize -> notifications/initialized -> tools/list and returns all 6 expected tools.\n- No corresponding MCP startup WARN/ERROR appears in the current process logs.\n\nThis isolates the failure after successful server initialization, around tool caching/attachment to the current session rather than server startup or backend health. A local runtime audit now detects this state from logs_2.sqlite.