codex - 💡(How to fix) Fix MCP tool invocation regressed for custom/local providers (Ollama Responses API) in v0.117.0+ [2 comments, 3 participants]

What version of Codex CLI is running?

Bisected with the same Codex config and MCP server set:

• 0.115.0: good
• 0.116.0: good
• 0.117.0 through 0.125.0: MCP tool invocation becomes unreliable for custom/local model providers
• 0.126.0-alpha variants tested during investigation: still reproduced

I am currently pinning 0.116.0 only as a workaround for the custom/local provider path.

What subscription do you have?

Not applicable to the repro. This is a custom model provider path using a remote Ollama/OpenAI-compatible endpoint, not an OpenAI-hosted model invocation.

Which model were you using?

Primary repro: gpt-oss:120b served by Ollama through an OpenAI-compatible /v1 endpoint with wire_api = "responses".

I also reproduced the same class of failure with other Ollama-served models through the same Codex provider/config shape, including qwen3.5:122b, qwen3.6:35b-a3b-bf16, and gemma4:31b. One vision model profile can also stall in some runs, but the simpler text-model repro is enough to show the MCP dispatch regression.

What platform is your computer?

Linux x86_64. The current deployed host reports Linux 6.8.0-100-generic.

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

The clearest repro is non-interactive codex exec from a shell. My local helper script is not intended to be the interesting part of the report: it renders config.toml, sets CODEX_HOME, chooses a profile, and then execs Codex.

The important command shape is equivalent to:

printf '%s\n' '<prompt>' | CODEX_HOME=/tmp/codex-local codex exec \
  --profile=local-ollama \
  --cd /path/to/workspace \
  --skip-git-repo-check \
  --dangerously-bypass-approvals-and-sandbox \
  -

What issue are you seeing?

For custom/local model providers using the Responses wire API, Codex 0.117.0+ often fails to invoke registered MCP tools even when the prompt explicitly requires tool use.

The session starts, the MCP server list can show the relevant server as ready, and other tool surfaces such as shell execution may still work. The failure is that Codex does not emit the expected MCP tool call. With the same config and prompt on 0.115.0 or 0.116.0, the transcript includes a real tool call such as:

tool brave_search.brave_web_search({...})

On regressed versions, the model frequently answers without making the MCP call, or otherwise fails to dispatch the registered tool despite it being available.

This looks like a Codex custom-provider/tool-routing regression rather than a generic MCP server startup issue. The same MCP servers and same model-provider config are usable on the known-good versions, and the regression starts at 0.117.0 in my bisect.

What steps can reproduce the bug?

Use a custom provider backed by Ollama or another OpenAI-compatible endpoint, with the Responses wire API and at least one MCP server that is easy to force from the prompt.

Representative config shape:

model_provider = "remoteollama"
model = "gpt-oss:120b"

[model_providers.remoteollama]
name = "Ollama"
base_url = "http://<ollama-host>:11434/v1"
wire_api = "responses"

[profiles.local-ollama]
model_provider = "remoteollama"
model = "gpt-oss:120b"
model_context_window = 131072
model_catalog_json = "/path/to/model-catalog.json"
approval_policy = "never"
sandbox_mode = "danger-full-access"

[mcp_servers.brave_search]
startup_timeout_sec = 60
command = "<brave-search-mcp-command>"
args = ["..."]

The catalog entries mark these models as API-supported and define their context windows/reasoning metadata; they are ordinary Codex model catalog entries, not special wrapper logic.

Then run an explicit MCP-forcing prompt:

printf '%s\n' 'Use the brave_search tool, not shell, to find the special comedian guest for the 2026 White House Correspondents Dinner. Return only the name and one source URL.' \
  | CODEX_HOME=/tmp/codex-local codex exec --profile=local-ollama --cd /path/to/workspace -

If MCP startup is slow on the first invocation, run a simple warm-up prompt first and judge the second run:

printf '%s\n' 'Reply with exactly READY.' \
  | CODEX_HOME=/tmp/codex-local codex exec --profile=local-ollama --cd /path/to/workspace -

Expected comparison:

• 0.115.0 / 0.116.0: after MCP startup, the transcript emits a real brave_search MCP tool call and returns the sourced answer.
• 0.117.0+: MCP startup may still show brave_search ready, but Codex no longer reliably emits the MCP tool call for the same prompt/config/provider.

What is the expected behavior?

Once an MCP server is started and available, a prompt that explicitly requires brave_search or web_search should reliably produce a real MCP tool call for custom/local provider models, matching the behavior seen in 0.115.0 and 0.116.0.

The custom-provider path should not require pinning an older Codex binary solely to preserve MCP tool invocation.

Additional information

My deployment has extra scaffolding that I do not think is essential to the bug: a VM image build, envsubst/envconsul config rendering, Dockerized MCP server images, persistent CODEX_HOME, and a small wrapper script used to select profiles. Those details explain why I noticed the regression, but the wrapper is not doing tool dispatch. It ultimately renders normal Codex config and runs codex exec --profile=... --cd ... -.

The current workaround in my environment is to install two Codex binaries:

• 0.116.0 for Ollama/custom-provider profiles because MCP calls still work there
• a newer Codex build for the OpenAI gpt-5.5 profile because the older binary is no longer a practical OpenAI runtime

This is only a compatibility bridge. It is not evidence that newer versions restored custom-provider MCP tool calling.

Related upstream signals that may be relevant:

• Closed issues in the same general area: #1558, #7517, #8829
• Open issue from the same release window: #16335
• MCP/tool-routing PRs around this period: #17556 and #18413