A Destructive MCP Tool Call Still Needs Approval

The mistake

Running Codex under an approval mode that never prompts — expecting a fully unattended session — and connecting an MCP server whose tools are annotated as destructive, then being surprised when the session stops and asks anyway, apparently contradicting the approval setting you deliberately chose.

Why this happens

Destructive tool calls carry a stronger rule than your own approval configuration: when a tool advertises a destructive annotation, approval is required regardless of what sandbox or approval mode is otherwise active — even if that same tool also happens to carry a read-only hint alongside the destructive one. It's a deliberate override, not a bug, and it means "never prompt" genuinely means "never prompt for anything that isn't independently flagged as destructive," which is a narrower promise than the flag's name suggests at a glance.

Why it matters

An automation built around a supposedly-unattended approval mode will stall the moment it hits a destructive-annotated tool call, which is exactly the failure mode a fully automated pipeline is least prepared to handle gracefully — there's no human present to answer the prompt, and depending on how the pipeline is wired, a stalled approval can mean a hung process rather than a clean failure.

The fix

Design any genuinely unattended pipeline around the assumption that a destructive-annotated tool call will always stop and wait, and either avoid connecting MCP servers whose tools carry that annotation in unattended contexts, or build the pipeline to handle a stalled approval as an expected outcome rather than an anomaly. This override exists specifically so that "never prompt" can't be used to silently approve genuinely destructive actions, which is a safety property worth keeping rather than working around.

It's also a reason to actually read what an MCP server's tools claim about themselves before connecting it to any pipeline meant to run unattended — a server whose destructive-annotated tools are exactly the ones your pipeline needs to call routinely is simply a poor fit for full automation, no approval configuration will make it behave otherwise.

See also

Approving a Destructive Tool Call Safely covers what to actually do when this prompt appears in an interactive session, rather than an unattended one.