Codex CLI Ignores Available MCP Servers Until Manually Prompted
I think Codex CLI has an issue with MCP loading and discovery. I’ve run multiple sessions, and unless I nudge the model to use a specific MCP server or tool, it doesn’t seem to recognize they exist. I have to keep prompting it until it uses them, at which point they become available in context. However, if it encounters a problem that another MCP server could help in solving, it still doesn’t recognize that it has the right tool for the job. I’m not sure if this is an issue with Codex itself or the GPT model, but it tends to stick to raw terminal commands rather than using the MCP tools I provide. I’ve tried GPT models in other harnesses, and while they were generally weaker at discovering and using tools than other providers, something like OpenCode was much better at finding and using MCP servers compared to Codex. I’d like to point this out in case others have seen the same issue and to figure out steps to reproduce it so it can be fixed. Also, every time you type /new, it reloads the MCP servers and makes you wait, which feels unnecessary. Other harnesses load them once in the background without forcing me to wait for MCP server initialization.
codex-cli 0.141.0
Windows:
Edition Windows 11 Pro
Version 25H2
OS build 26200.8655
Experience Windows Feature Experience Pack 1000.26100.315.0
GPT model used: GPT 5.5- high
Terminal: Windows Terminal
Shell: Powershell
6 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
This sounds like a tool discovery and planning-surface problem rather than only an MCP transport problem.
A useful repro would separate three cases:
Those are different failure modes. The first is runtime/config loading. The second is prompt/tool-ranking behavior. The third is a session memory or tool-salience issue.
For debugging, I would capture the initial tool manifest for a fresh session, then run the same prompt twice: once with no hint and once with an explicit "use the configured MCP server if relevant" hint. If the hinted run succeeds while the unhinted run ignores the tool, the server is probably loaded and the issue is tool selection/planning.
The UX fix might be to expose an explicit "available tools" summary early in the session, plus a warning when a configured MCP server is loaded but never considered during planning.
This should be debugged as a tool-inventory salience pipeline. Capture three snapshots per turn: configured MCP servers, runtime-visible MCP tools, and model-visible tool inventory included in the prompt/planning surface.
If a tool only becomes "available" after the user names it, record whether the initial inventory omitted it or whether ranking/planning ignored it. Also separate server startup latency from tool visibility; reloading every
/newshould have a cached manifest state with freshness and retry metadata.---
_Generated with ax._
Can confirm this behavior. Worked pretty well for some time, but since a few weeks now, it completely ignores all mcp related instructions (in my case, all AGENTS files contain mcp usage instructions).
This sounds like an effective-tool-inventory salience problem, not just MCP connectivity.
A useful diagnostic would record, per turn: configured MCP servers, connected MCP servers, runtime-visible tools, model-visible tool names/descriptions, tools deferred behind discovery, and which instruction/source made a tool relevant. If the model can call a tool only after the user names it, the runtime likely has a gap between “available” and “discoverable/plannable.”
I maintain Better Agent (https://github.com/ofekron/better-agent), where provider integrations keep availability, policy, and model-facing discovery as separate states for this reason. If useful, a star helps other MCP-heavy Codex users find it.
We see exactly the behavior described here, and we happen to measure it daily, so I can add some numbers.
Three CLIs (Codex, Claude Code, Cursor) get the same natural prompts against the same MCP server, through a proxy that logs every call.
Over 6 days Codex picked an MCP tool in 4 out of 70 prompts. Claude Code and Cursor, on the same prompts and same tool list, sit at 66% and 93%. And Codex fetches the tool list on every prompt, so it sees the tools. It reads them, then ignores them.
The hint strength needed surprised us. "Use the survey tool from this server" was not enough: 0 out of 3 runs called the tool. A fully explicit command works: "Use the <server> MCP server: run its
surveytool. Call the tool now, do not answer from your own knowledge" called it 3 out of 3 times. So connection and calls all work, but anything short of a direct order gets ignored.codex-cli 0.146.0, Linux, gpt-5.5, API key auth.