Repository navigation
Codex MCP tool calls fail #1333
Description
Symptom
Codex turns cannot successfully invoke MCP tools (coder-memory, coder-threads / Planboard, and user-registered servers). The tools may appear in the prompt or the advertised tool list, but the call fails at dispatch/execution so the turn cannot read memory, write Planboard issues, or use any other MCP server.
This is the Codex counterpart of the Cursor injection gap that #700 fixed, and it is still happening after the Planboard Codex bind work in #927 / #1163.
Expected
A Codex thread in a bound project should be able to call the same first-party MCP tools Claude / Grok / Cursor can: memory_bootstrap, Planboard issue_*, and any project-registered MCP servers. Failures should surface as a readable tool error in the thread, not a silent no-op or an opaque JSON-RPC error.
Related (not duplicates)
- Cursor runs get no MCP injection: memory, orchestration, preview, spec/teach all dead — and prompts advertise the missing tools #700 — Cursor runs got no MCP injection (fixed)
- Codex sessions advertise Planboard MCP writes but omit issue tools and reject authorized GitHub writes #927 / Bind ?projectId= on Codex coder-threads MCP so Planboard issue tools appear #1163 — Codex Planboard writes were advertised but tools were missing / GitHub writes rejected (fixed)
- Codex MCP tool images never appear in the thread #1021 — Codex MCP tool images never appeared (fixed)
- Codex permissions overlay and MCP elicitation / requestUserInput cards #1190 — Codex MCP elicitation /
requestUserInputcards (open, different surface: mid-call prompts, not the invoke itself) - MCP elicitation requests are auto-errored; mid-run questions from MCP servers never reach the user #173 — MCP elicitation auto-errored (open, same: elicitation, not dispatch)
Repro
- Open a Codex thread on a project that has coder-memory + coder-threads MCP configured.
- Ask it to call
memory_bootstraporissue_list. - Observe the tool call fail (not advertised, not dispatched, or JSON-RPC error) instead of returning a result.
Notes
No stack trace captured on this ticket. First debugging pass should distinguish:
- tools never injected into the Codex harness
- tools advertised but
call_tool/ app-server invoke never sent - invoke sent, MCP server errors
- invoke succeeds but Solenta drops / mis-renders the result (see Codex MCP tool images never appear in the thread #1021)
Activity
currentbits commentedon Sep 27, 2026
Investigating the report that Codex has MCP failures across multiple servers, including Girder, while other providers work.
Plan:
No production deployments or MCP configuration changes are part of these diagnostic probes.
currentbits commentedon Sep 27, 2026
Investigation result (2026-09-27): Codex MCP approval requests are rejected by Solenta
The primary reproducible failure is before tool execution, not server connectivity or result rendering.
Verified path
mcpServer/elicitation/request, form mode,_meta.codex_approval_kind = "mcp_tool_call".electron/codexApprovals.js:26-30explicitly classifies this method unsupported.electron/runner.js:2406-2417responds with JSON-RPC -32601 instead of showing a permission card.user rejected MCP tool call. No human was asked and the MCP server never receives tools/call.This code is identical on the investigation checkout and published main at 93d3dcc.
Live reproduction
Installed Codex 0.157.1, isolated CODEX_HOME and temporary cwd, one harmless local stdio MCP tool
diagnostic_ping, no production services or config changes. Used Solenta's actual JSON-RPC transport plus classifyServerRequest/unsupportedError helpers.The control response was
{action:"accept",content:{},_meta:null}. Assertions checked discovery, request kind, actual server call counts, and both outcomes. A direct host-sidemcpServer/tool/callsucceeds without this approval flow, so it is not a valid reproduction by itself: the model-initiated call is essential. Temporary auth copies were removed.Girder evidence
Project transcript contains three Girder deploy_plan failures (September 11 and 22) and two Playwright browser_navigate failures (September 11), all with exactly
user rejected MCP tool call. Current thread provider can change later; these tool records use Codex's MCP item format.Girder's configured MCP transport initialized successfully and returned 72 tools. All 72 have no annotations, including read-only deploy_plan and list_deploys. The independent, read-only
list_deploys(app=solenta)call succeeded. Missing readOnlyHint makes even read-only Girder calls require approval under Codex's default rules. No deployment was attempted.Pinned upstream policy: https://github.com/openai/codex/blob/rust-v0.157.1/codex-rs/core/src/mcp_tool_call.rs (
requires_mcp_tool_approval,requires_mcp_tool_approval_for_mode, andrequest_mcp_tool_approval).Why providers differ
Historical failures are separate: two September 3 startup HTTP401 records and nine September 3-5 never-policy approval failures also exist. Do not treat every MCP error or a server's legitimate application rejection as this bug.
Smallest corrective scope
Implement the MCP tool-approval form variant in Solenta's shared Codex request/permission path, with correct accept/decline/cancel responses, request IDs, stop/late-reply handling, and clear unsupported-request reporting. Preserve real approval decisions; do not blanket-approve all third-party tools. General MCP forms/URL elicitation and requestUserInput remain broader #1190 work. Girder should separately annotate genuinely read-only tools.
Investigation is complete; production fix remains open. Local reproduction scripts and logs are in
/tmp/solenta-mcp-investigation/on the investigating machine.currentbits commentedon Sep 28, 2026
Fixed by #1370, merged as fc354cc and published in nightly-202609280651-fc354ccb. Ordinary Codex MCP tool confirmation requests now reach the permission card, with method-correct allow/deny/cancel replies instead of unsupported RPC errors. A real Codex 0.157.1 model-initiated diagnostic tool call completed through this path. All six hosted checks passed at the identical PR tree 1a19ebb (run 36387517093). macOS nightly notarization, Gatekeeper, dependency resolution, and isolated boot verification passed; all three uploaded archive checksums match. Arbitrary mid-call forms remain tracked by #1190.