Codex bug: MCP servers load successfully but their tools aren't exposed to the model

Resolved 💬 3 comments Opened May 2, 2026 by someshds Closed May 2, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Codex bug: MCP servers load successfully but their tools aren't exposed to the model

Suggested title for the issue:

MCP servers configured in [mcp_servers.X] load successfully but their tools are not surfaced to the model in the session

Suggested repo: openai/codex

---

Description

A user-defined MCP server configured under [mcp_servers.<name>] in ~/.codex/config.toml is spawned correctly and completes the MCP handshake (verified in logs), but the Codex session's tool list shown to the model contains only Codex-managed plugins (github, vercel, google-calendar, notion). The user-defined server's tools never appear, so the model can't invoke them.

Environment

  • codex-cli: 0.128.0
  • macOS: 14.x

Configuration

[mcp_servers.agent-state]
command = "bash"
args = ["/Users/<user>/.codex/mcp-wrappers/agent-state.sh"]

The wrapper resolves credentials from 1Password and execs a Node.js MCP server. Both work standalone — running the wrapper from a Terminal produces the expected agent-state-mcp ready stderr line and the server accepts tools/list requests.

Evidence the server loads + responds

From ~/.codex/logs_2.sqlite:

level=TRACE target=rmcp::service
serve_inner: new event evt=PeerMessage(Response(JsonRpcResponse {
  jsonrpc: JsonRpcVersion2_0,
  id: Number(1),
  result: ListToolsResult(ListToolsResult {
    meta: None,
    next_cursor: None,
    tools: [
      Tool { name: "event_log", title: None, description: Some("..."), ... },
      // ...13 more tools
    ]
  })
}))

So at the protocol layer, Codex received the catalog of 14 tools.

What the model sees

When prompted "list all available tools", the model reports only github, vercel, google-calendar, notion — the four [plugins.*] entries from config.toml. It does not mention the agent-state server or any of its 14 tools, and direct invocations like "call the tool named event_log" return "no such tool."

Expected behavior

Tools from [mcp_servers.X] entries should be visible alongside [plugins.X] tools in the model's tool registry.

Reproduction

  1. Configure any MCP server under [mcp_servers.X] in ~/.codex/config.toml (a public stdio MCP like the GitHub MCP or a tiny local hello-world MCP works for repro)
  2. Launch codex
  3. Verify in ~/.codex/logs_2.sqlite that rmcp::service recorded ListToolsResult for the server (proves it loaded)
  4. Inside the Codex session, ask the model to list available tools
  5. The user-defined server's tools are absent from the model's response

Hypothesis

Looks like there's a registration step between rmcp receiving the tool list and the session tool-registry being populated for the model. Either the registration call is missing, or the session's tool-list serialisation is filtering out non-plugin entries.

Workaround

None found. [plugins.*] entries work; [mcp_servers.*] entries connect but are unusable from the agent's perspective.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

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

  • #19649
  • #19425
  • #20009
  • #19304

Powered by Codex Action

etraut-openai contributor · 3 months ago

Looks like a duplicate of #19425.

qingq4863-coder · 4 days ago

Same symptom here (Windows 11; npm installs of 0.147.0 / 0.148.0 / 0.149.1): all [mcp_servers.*] servers complete their stdio handshake, but zero mcp__<server>__<tool> functions are registered into the model's toolset — only the built-in meta tools (list_mcp_resources, list_mcp_resource_templates, read_mcp_resource) plus regular builtin tools remain. [plugins.*] tools are unaffected.

What may help locating this: the same machine produced successful mcp__context7 / mcp__chrome_devtools / mcp__node_repl calls through 2026-08-19 on codex-cli 0.147.0, and today the same binary re-run via npx -y @openai/codex@0.147.0 (fresh TUI session, same config home) exposes none of them. So on our box this is not purely a version regression — something changed in the environment/state between 08-19 and 08-24 that breaks MCP tool wiring across all versions.

Discrimination matrix run today (2026-08-24), each row followed by an immediate headless codex exec probe asking the model to list mcp__* tools:

| Experiment | Result |
|---|---|
| Remove newly-added server entry from config.toml | other servers' tools still missing → not entry poisoning |
| Comment out entire [features] block (hooks, multi_agent) | still missing |
| Disable ALL [plugins.*] entries | still missing |
| Run from a different cwd/project trust level | still missing |
| Different model providers (all third-party API-key based, both eras) | still missing |
| Re-run previously-working 0.147.0 via npx | still missing TODAY |

Additional observations:

  • A SessionStart hook fires even with every [plugins.*] disabled and [features] removed — suggesting a hook layer outside user config that appeared or changed in the same 08-19 → 08-24 window.
  • Desktop app (26.609.41114) shares CODEX_HOME with the CLI; its .codex-global-state.json has not been modified since July, so the trigger seems to sit elsewhere.
  • Server side verified healthy: stock npx @modelcontextprotocol/inspector --cli <cmd> completes initialize → tools/list → tools/call successfully against one of the affected servers, so this looks purely like codex-side tool registration/exposure rather than a server conformance issue.
  • codex mcp list / codex mcp get show all servers enabled and correctly configured throughout.

Happy to run additional probes, provide redacted rollout files, or test candidate patches.