Fix "user cancelled MCP tool call" in codex exec
When codex exec cancels MCP tool calls right away, drop the config keys that do nothing, approve per server or tool with approval_mode, and keep the sandbox on.
mcp: spike/echo_hello startedmcp: spike/echo_hello (failed)user cancelled MCP tool callIssue openai/codex#24135 reports this in non-interactive codex exec (version 0.130.0). No one is there to answer the approval prompt, so the call is cancelled, and most of the keys the reporter tried to prevent it did nothing. If the server never starts, see Fix Codex "MCP client for … timed out". This post covers the case where the server is up but the call is cancelled.
[1] Write the config, then load it with --strict-config. Without it, unknown keys are silently ignored.
$ codex --strict-config exec --skip-git-repo-check "hi"[2] Here is what 0.163.0 does with the keys from the issue. approval_policy under a server table is rejected too.
[mcp_servers.spike]command = "python3"args = ["mock.py"]approval_policy = "never"Error loading config.toml:~/.codex/config.toml:5:1: unknown configuration field `mcp_servers.spike.approval_policy`| Key | Where | Result on 0.163.0 |
|---|---|---|
approval_policy | top level | accepted (untrusted · on-failure · on-request · granular · never) |
approval_policy | under [mcp_servers.x] | unknown configuration field |
default_tools_approval_mode | top level | unknown configuration field |
tools_require_approval · mcp_approval_policy · trusted_mcp_servers | top level | unknown configuration field |
[3] Top-level approval_policy = "never" is about the shell commands the model runs. MCP tool approval has its own keys. 0.163.0 accepts default_tools_approval_mode under the server table and approval_mode per tool, with one of auto, prompt, writes, approve.
[mcp_servers.spike]command = "python3"args = ["mock.py"]default_tools_approval_mode = "approve"A bad value fails at load time.
~/.codex/config.toml:4:31: unknown variant `bogus`, expected one of `auto`, `prompt`, `writes`, `approve`[4] To open a single tool, put the setting under the tool name. That is narrower than approving the whole server.
[mcp_servers.spike]command = "python3"args = ["mock.py"] [mcp_servers.spike.tools.echo_hello]approval_mode = "approve"This matches the workaround a Windows user posted in the issue thread: approval_policy = "never" alone was not enough, but writing approval_mode = "approve" for each needed tool let the calls through.
[5] Set the sandbox separately. Approval and sandbox are different settings and do not stand in for each other.
$ codex --strict-config exec -s read-only --skip-git-repo-check "call the echo_hello tool"--dangerously-bypass-approvals-and-sandbox removes every approval check and turns the sandbox off. Its help text reads "EXTREMELY DANGEROUS. Intended solely for running in environments that are externally sandboxed". That is why the reporter wanted to keep -s read-only instead. Use the flag only inside an environment that is already isolated from outside, such as a container.
[6] The message differs by version. A comment on the issue reports that on 0.160.0 the call fails before dispatch with MCP tool call requires approval, but approval policy is never. Both strings are present in the 0.163.0 binary. Whichever you see, add the approval_mode from steps 3–4 and rerun the same command. What decides between the two messages was not determined.