MCP tool invocation regressed for custom/local providers (Ollama Responses API) in v0.117.0+

[neurostream]

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: No tooling is called when using local providers like Ollama #1558, Tool call streaming broken in 0.64.0 with local LLM providers #7517, Error executing command in Codex CLI: BadRequestError with multiple missing fields and invalid types using gpt-oss-120b with wire_api responses #8829
• Open issue from the same release window: TUI/CLI performance regression from 116 to 117 #16335
• MCP/tool-routing PRs around this period: [codex] Support flattened deferred MCP tool calls #17556 and [tool search] support namespaced deferred dynamic tools #18413

[github-actions]

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

• MCP servers registered but tools not injected into threads in Codex CLI >=0.120.0 #19649
• codex can not find mcp #19815

Powered by Codex Action

[truffle-dev]

The two pinned candidates look like sibling MCP regressions on different layers, not duplicates of this one.

• codex can not find mcp #19815 is a discovery-layer bug: "codex can not find mcp" with chrome-devtools-mcp and context7-mcp via npx on Windows. MCP servers never register at all (different from this issue, where servers register successfully and codex mcp list shows them).
• MCP servers registered but tools not injected into threads in Codex CLI >=0.120.0 #19649 is a tool-injection-layer bug: 0.120.0 good → 0.122.0-alpha.13 bad on macOS with hosted gpt-5.4. Servers register, tools are visible via codex mcp list / codex mcp get, but the tools "are not exposed inside new Codex threads" (no mcp__server__tool calls reach the model).
• This issue (MCP tool invocation regressed for custom/local providers (Ollama Responses API) in v0.117.0+ #19871) is a tool-invocation-layer bug: 0.115/0.116 good → 0.117–0.125 bad on local Ollama via wire_api = "responses". Servers register, tools register, the model sees them, but dispatch fails.

The bisect windows also differ. #19649 places the regression between 0.120.0 and 0.121.x; this issue places it earlier, between 0.116 and 0.117. If they share a root cause, the local-provider responses-API path was sensitive to the change ~3 versions before the hosted path noticed it.

Worth keeping #19871 distinct so the responses-API-specific repro (and the cross-model evidence: gpt-oss:120b, qwen3.5:122b, gemma4:31b, qwen3-vl:235b) doesn't get folded into a hosted-only triage.

[DinoLabAI]

I've been working on an agent with multiple external tools — API lookups, search, live data. When tools fail (timeouts, empty responses, bad data), the model does one of two things: surfaces the raw error to the user, or answers from memory as if the tool worked. Neither is usable.

What I actually want is specific acknowledgment of the failure plus a useful alternative. Not "Error: connection timeout." Not a fabricated answer. Something like: tool unavailable, here's what you'd need to check this yourself, here's what matters when you do.

Built training data for this exact gap. One row from DinoDS Lane 33 (Fallback Behavior):

JSONL Row (public proof):

{"sample_id": "lane_33_spec_example_03", "mode": "conversation", "tone": "friendly", "intent_family": "qa_general", "intent_subtype": "no_guarantees", "user_message": "Give me the exact stock price right now.", "assistant_response": "I can't guarantee an exact real-time price in this chat. If you tell me the ticker and your market, I can explain how to check the current quote and what numbers matter (last trade vs. bid/ask vs. after-hours)."}

Still not sure whether this covers multi-tool cascade failures well — where the first tool fails and the model has to decide whether to try a fallback tool or degrade gracefully. Probably a separate training surface or a superset of rows. Dataset exists. Full bundle available via Discord and Platform.

[rnett]

I am seeing the same thing. I suspect it's related to the namespacing not looking like typical tool calls.

> ollama launch codex
╭────────────────────────────────────────────────────╮
│ >_ OpenAI Codex (v0.128.0)                         │
│                                                    │
│ model:     glm-5.1:cloud medium   /model to change │
│ directory: ~\Projects\Personal\agent-config        │
╰────────────────────────────────────────────────────╯

  Tip: New Build faster with Codex.


› What mcp tools do you have available?


⚠ Model metadata for `glm-5.1:cloud` not found. Defaulting to fallback metadata; this can degrade performance and cause issues.

• - Access repositories, issues, and pull requests

  2. mcp__context7__ - Fetch current documentation for libraries, frameworks, SDKs, etc.
  3. mcp__gradle__ - Gradle-related tools
  4. mcp__playwright__ - Playwright browser automation tools
  5. mcp__tavily_mcp__ - Tavily search tools
  6. mcp__tilth__ - Code intelligence (AST-aware search, read, edit, diff, etc.)

  Let me also check if I can list the actual tool names from each server by listing MCP resources.

• Here are the MCP servers and their tools I have access to:

  mcp__tilth__ — Code intelligence server (AST-aware replacements for grep/cat/find/diff)

  - tilth_search — Search code for definitions, usages, and text (replaces grep/rg)
  - tilth_read — Read files with smart outlining (replaces cat/head/tail)
  - tilth_files — Find files by glob pattern (replaces find/ls)
  - tilth_edit — Edit files using hash-anchored lines (replaces Edit tool)
  - tilth_diff — Structural diff at function level (replaces git diff)
  - tilth_deps — Blast-radius check for renames/signature changes

  mcp__context7__ — Documentation fetcher

  - Fetches current docs for libraries, frameworks, SDKs, APIs, CLI tools, and cloud services

  mcp__tavily_mcp__ — Web search

  - Tavily-powered web search for ad-hoc research queries

  mcp__playwright__ — Browser automation

  - Playwright tools for browser interaction and testing

  mcp__gradle__ — Build system tools

  - Gradle-specific MCP tools for dependency management and builds

  mcp__codex_apps__github — GitHub integration

  - Access repositories, issues, and pull requests


› Try calling gradle or tilth tools


⚠ Model metadata for `glm-5.1:cloud` not found. Defaulting to fallback metadata; this can degrade performance and cause issues.

• Let me try listing resources from both servers and also call a tilth tool directly.Let me try the server names without the prefix:Both servers exist but don't support resource listing. Let me try calling actual tools — a tilth_search on this repo and a Gradle tool to see what's available:The MCP servers for both tilth and gradle are configured but don't seem to be exposing their individual tools properly in this session:

  - Resource listing: Both servers reject resources/list (tilth returns "method not found", gradle returns "not supported")
  - Direct tool calls: Both return "unsupported call" when invoked
  - Resources/templates: No resources or templates registered

  This typically means the MCP server processes may not be running or the tool schemas weren't loaded at session start. The individual sub-tools (like tilth_search, tilth_read, tilth_edit etc.) should appear as separate callable functions but they're not showing up.

  You might want to check:

  - Are the tilth and gradle MCP server processes running?
  - Is the MCP config (e.g. in codex/config.toml or the Codex MCP settings) pointing to the right server executables?
  - Does restarting the Codex session pick them up?

  Want me to dig into the MCP server configuration to troubleshoot?

• Called mcp__gradle__.list_mcp_resources({"server":"mcp__gradle__"})
  └ Error: resources/list failed: unknown MCP server 'mcp__gradle__'

• Called mcp__tilth__.list_mcp_resources({"server":"mcp__tilth__"})
  └ Error: resources/list failed: unknown MCP server 'mcp__tilth__'

• Called gradle.list_mcp_resources({"server":"gradle"})
  └ Error: resources/list failed: resources/list failed for `gradle`: Mcp error: -32601: Server does not support resources/list({})

• Called tilth.list_mcp_resources({"server":"tilth"})
  └ Error: resources/list failed: resources/list failed for `tilth`: Mcp error: -32601: method not found: resources/list

• Calling codex.list_mcp_resources({})

• Calling codex.list_mcp_resource_templates({})

• Called codex.list_mcp_resources({})
  └ {"resources": []}

• Called codex.list_mcp_resource_templates({})
  └ {"resourceTemplates": []}

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────


› The issue is your calling syntax


⚠ Model metadata for `glm-5.1:cloud` not found. Defaulting to fallback metadata; this can degrade performance and cause issues.

• Ah, let me try different calling patterns.Let me try a few different calling patterns:The tools have now gone unavailable entirely. I've tried several calling patterns without success:

  - Direct params: {"query": "AGENTS", "kind": "symbol"}
  - Sub-tool names: mcp__tilth__tilth_search
  - Name/arguments wrapper: {"name": "tilth_search", "arguments": {...}}

  Could you show me the correct calling syntax? I'm clearly missing something about how these MCP namespace tools should be invoked.

[truffle-dev]

That transcript matches the shape: the model emits text describing MCP tools (mcp__tilth__ — Code intelligence server) instead of producing a tool_use invocation. That points at the regression being on the responses wire path: namespaced tool names register on the server side but no longer round-trip to a real tool call between 0.116 and 0.117.

Two things that would tighten the bisect:

1. Does pinning 0.116.0 with the same glm-5.1:cloud config restore the actual tool call? Same regression line on a second provider/model pair rules out anything model-specific in gpt-oss:120b.
2. Is your provider config also wire_api = "responses"? The chat path was unchanged across that range, so confirming responses locks the scope.

A redacted config.toml paste would help narrow the maintainer search.