›_ Codex Issues
Codex Issues / #16685

MCP tool calls always cancelled in exec mode with 'user cancelled MCP tool call'

Open 💬 8 comments Opened Apr 3, 2026 by murataslan1
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Bug Description

All MCP tool calls are immediately cancelled when using \codex exec\ mode. This affects every MCP server, not just specific ones.

Reproduction

1. Any MCP server in \~/.codex/config.toml\:
\\\toml
[mcp_servers.minimal]
command = "node"
args = ["/path/to/any-mcp-server.js"]
\\\

2. Run exec mode:
\\\bash
codex exec --json --full-auto "Call the MCP tool"
\\\

3. Observed JSONL output:
\\\json
{"type":"item.started","item":{"type":"mcp_tool_call","server":"minimal","tool":"count","status":"in_progress"}}
{"type":"item.completed","item":{"type":"mcp_tool_call","server":"minimal","tool":"count","status":"failed","error":{"message":"user cancelled MCP tool call"}}}
\\\

Key Evidence

  • Reproduces with the trivial MCP SDK example server (the \count\ tool from \@modelcontextprotocol/sdk/examples/server/progressExample.js\) — not specific to any particular MCP server
  • Direct stdio MCP client calls to the same servers succeed — the servers themselves are healthy
  • Removing all hooks and AGENTS instructions doesn't change the behavior — hooks are not involved
  • Codex log outputs: \request_user_input is not supported in exec mode\
  • \codex features list\ shows \codex_hooks = false\

Diagnosis

Codex exec mode appears to hit an MCP elicitation/user-input path during tool invocation. Since exec mode doesn't support interactive input, this triggers cancellation of the MCP tool call.

The cancellation happens very quickly after the tool call starts — it's not a timeout, it's an early abort.

Environment

  • codex-cli 0.118.0
  • macOS (Apple Silicon)
  • Node.js v22.22.0
  • Multiple MCP servers tested (context-mode, minimal SDK example)

Full Session Report

Detailed investigation with exact commands, outputs, and chronology:
https://gist.github.com/murataslan1/e0290cb0862f57fff4a0e2936b6a77d8

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 3 months ago

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

  • #15824
  • #16394

Powered by Codex Action

murataslan1 · 3 months ago

After reviewing the flagged duplicates:

  • #15824 looks like the same root cause — MCP tool calls entering the RequestUserInput approval flow ("Approve app tool call?") which blocks/cancels in non-interactive contexts. That issue reports it from the test suite side (cargo test timeouts), this issue reports it from codex exec mode (where it surfaces as user cancelled MCP tool call). Same underlying path: maybe_request_mcp_tool_approval() called unconditionally in mcp_tool_call.rs.
  • #16394 is different (closed, was about danger-full-access permission prompts).

If maintainers consider this a duplicate of #15824, happy to close. The exec-mode reproduction and the request_user_input is not supported in exec mode log from this issue might still be useful as additional signal on #15824.

etraut-openai contributor · 3 months ago

Thanks for the bug report. Do you have reason to suspect that this is a recent regression (e.g. in 0.117.0 or 0.118.0)? If you roll back to 0.116.0, are you able to repro the problem? I ask for a couple of reasons. First, this influences the priority of the fix. Second, this is the first report of this that we've received, which seems odd if this is a general problem. That might mean that it's related specifically to your configuration or the MCP server that you're using.

murataslan1 · 3 months ago

@etraut-openai Yes — this is a regression. Rolled back to 0.116.0 and the same minimal MCP server works fine:

0.116.0 — MCP tool call succeeds:

{"type":"item.started","item":{"type":"mcp_tool_call","server":"minimal","tool":"ping","status":"in_progress"}}
{"type":"item.completed","item":{"type":"mcp_tool_call","server":"minimal","tool":"ping","result":{"content":[{"type":"text","text":"pong"}]},"status":"completed"}}

0.118.0 — same server, same config, MCP tool call cancelled:

{"type":"item.started","item":{"type":"mcp_tool_call","server":"minimal","tool":"ping","status":"in_progress"}}
{"type":"item.completed","item":{"type":"mcp_tool_call","server":"minimal","tool":"ping","status":"failed","error":{"message":"user cancelled MCP tool call"}}}

The minimal server is a trivial ping → pong tool using @modelcontextprotocol/sdk — nothing config-specific.

Potentially relevant feature flag change between versions:

  • 0.116.0: tool_call_mcp_elicitation = false
  • 0.118.0: tool_call_mcp_elicitation = true (now stable)

This suggests the regression may be related to the MCP elicitation feature becoming default-on between these versions.

Full regression test report with exact commands and JSONL output:
https://gist.github.com/murataslan1/e0290cb0862f57fff4a0e2936b6a77d8#file-codex-mcp-regression-test-0-116-0-2026-04-03-md

etraut-openai contributor · 3 months ago

OK, thanks for the confirmation. Very helpful!

SebastianBodza · 3 months ago

Thanks! Can confirm the same 0.116.0 is working.

murataslan1 · 3 months ago

@SebastianBodza thanks for confirming.

For anyone following — the fix is in #16632 (custom MCP tools without annotations were hitting the app-tool approval path, which auto-cancels in exec mode). Still open though.

@etraut-openai any timeline on getting #16632 merged? Two independent confirmations of the regression now, and the fix looks solid with focused tests + manual exec validation.

njakubiak · 2 months ago

I am able to work around this issue using the argument "-s danger-full-access"