Codex bug: MCP servers load successfully but their tools aren't exposed to the model
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
- 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) - Launch
codex - Verify in
~/.codex/logs_2.sqlitethatrmcp::servicerecordedListToolsResultfor the server (proves it loaded) - Inside the Codex session, ask the model to list available tools
- 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.
3 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Looks like a duplicate of #19425.
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 zeromcp__<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_replcalls through 2026-08-19 on codex-cli 0.147.0, and today the same binary re-run vianpx -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 execprobe asking the model to listmcp__*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:
SessionStarthook 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.CODEX_HOMEwith the CLI; its.codex-global-state.jsonhas not been modified since July, so the trigger seems to sit elsewhere.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 getshow all servers enabled and correctly configured throughout.Happy to run additional probes, provide redacted rollout files, or test candidate patches.