MCP tools return 'unsupported call' with custom Responses API provider (llama.cpp)

Summary

Codex Desktop with custom provider (wire_api = "responses") returns unsupported call for all MCP tools. Built-in tools work fine.

Environment

• Codex Desktop 26.602.40724 (macOS)
• llama.cpp master as custom provider
• Model: Unsloth Qwen3.6-27B-Q8_0_MTP
• MCP servers: tavily, firecrawl, context7, node_repl

Config

model_provider = "llama_cpp"
model = "Qwen3.6-27B-Q8_0_MTP.gguf"

[model_providers.llama_cpp]
base_url  = "http://llama-server:10000/v1"
wire_api  = "responses"
requires_openai_auth = false

[mcp_servers.tavily]
command = "npx"
args = ["-y", "tavily-mcp"]

Behavior

Model generates correct tool calls, Codex responds:

unsupported call: tavily_search

All MCP tools across all servers fail identically.

What works

• exec_command, list_mcp_resources, list_mcp_resource_templates, apply_patch ✅
• MCP servers functional via exec_command + curl ✅
• API keys valid (HTTP 200 from both tavily and firecrawl endpoints) ✅

What we tried (nothing helped)

1. npm_config_cache=/tmp/.npm-cache env var
2. Global npm install + absolute binary path instead of npx
3. Various sandbox configurations
4. Different model variants
5. Patched llama.cpp to flatten namespace tools (tools now properly sent to model)
6. --reasoning on/off on llama-server

Analysis

list_mcp_resources works (returns empty resources) but individual MCP tool calls fail.
This suggests the MCP server process lifecycle management differs for custom providers vs OpenAI.
When using custom provider with responses wire_api, Codex may not spawn MCP server processes
or the communication channel isn't established.

Related

Companion issue filed on llama.cpp for namespace/web_search handling.