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

[murataslan1]

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

[github-actions]

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

• Regression: non-codex_apps MCP tool calls block on app-tool approval prompt #15824
• "danger-full-access" keeps asking for MCP permissions #16394

Powered by Codex Action

[murataslan1]

After reviewing the flagged duplicates:

• Regression: non-codex_apps MCP tool calls block on app-tool approval prompt #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.

• "danger-full-access" keeps asking for MCP permissions #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]

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]

@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]

OK, thanks for the confirmation. Very helpful!