Approving a Destructive Tool Call Safely

A destructive-annotated MCP tool call stopping and asking for approval, even under an approval mode that otherwise never prompts, is the one moment where every other configuration you've set stops mattering — this is the standing exception this site references throughout its sandbox coverage, and it deserves a page of its own about what to actually do in the moment it happens.

Why this specific prompt deserves more attention than an ordinary one

Every other approval prompt is, in some sense, routine — a normal part of the configured boundary doing its job. This one is different: it's appearing specifically because a tool has flagged its own action as destructive, which means the server exposing that tool is telling you, directly, that what's about to happen can't be easily undone. Treating this prompt with the same quick, reflexive approval you might give a routine one undersells exactly the signal it's carrying.

What to actually check before approving

Read what the tool call is actually proposing to do, specifically — not just which tool is being invoked, but what arguments it's being invoked with, since the same tool can be genuinely benign with one set of arguments and genuinely destructive with another. Confirm the action matches what you'd actually expect given the task at hand; a destructive action that doesn't obviously connect to what you asked for is worth pausing on longer, not approving faster because it's slowing you down.

When it's reasonable to approve quickly

For a well-understood, frequently-used MCP server whose destructive-annotated tools you've reviewed and trusted before, and where the specific call clearly matches the task you're actively working on, approving promptly is entirely reasonable — this mechanism isn't meant to slow down every legitimate destructive action into a lengthy investigation, it's meant to prevent one from happening silently, unnoticed, without any check at all.

When to stop and investigate further

If the destructive action doesn't obviously connect to your current task, if it's from a server you haven't used much or don't fully trust yet, or if the specific arguments look different from what you'd expect given the instruction you gave, that's worth pausing on — asking Codex to explain why this specific action is necessary, or checking the MCP server's own documentation for what this tool actually does, before approving something you don't fully understand yet.

Why this override exists regardless of approval mode

The whole point of this exception surviving even a "never prompt" approval mode is that a genuinely unattended pipeline shouldn't be able to grant blanket approval to destructive actions just because nobody configured it to ask — if that were possible, "never prompt" could quietly become "approve everything including irreversible actions," which defeats the purpose of having a destructive-action distinction in tool annotations at all. The override exists specifically to make that particular failure structurally impossible.

What this means for pipelines that need to be genuinely unattended

If your workflow needs to run without any human present to answer this kind of prompt, the practical implication is that connecting an MCP server whose tools are routinely destructive-annotated is a poor fit for that specific unattended context — not because the mechanism is broken, but because a stalled approval with nobody available to answer it is worse for an unattended pipeline than simply not connecting a server whose normal operation would trigger this prompt regularly.

Building your own judgment about a given server's annotations over time

The more you work with a specific MCP server, the better calibrated your judgment becomes about which of its destructive-annotated calls are routine and expected versus genuinely worth extra scrutiny — this is exactly the kind of calibration this site recommends building deliberately rather than either approving everything reflexively or investigating everything exhaustively regardless of context.

The habit this page is ultimately recommending

Treat every destructive-tool-call prompt as a genuine decision point, not an obstacle to click through — read what's actually being proposed, confirm it matches your actual intent, and approve or decline based on that specific check rather than on how many times you've already approved something similar today. This is the one prompt on this whole site's sandbox coverage explicitly designed to survive every attempt to configure it away, and it's worth treating that design choice with the respect it was built for.

Why this is worth teaching explicitly to anyone new to a team's Codex usage

For a team onboarding new members to using Codex with MCP servers connected, this specific prompt is worth calling out explicitly rather than assuming everyone will naturally develop the right instinct for it on their own. A new team member who's never seen this prompt before may reasonably assume it's routine, the same as any other approval, and approve it with the same speed — walking through why this one specifically deserves a closer look, once, up front, is a small investment that prevents a real mistake later.

Declining an approval, and what happens next

It's worth knowing that declining this prompt isn't a dead end — a session that has a destructive action declined typically continues, adapting its approach or asking for clarification about how you'd like to proceed instead. Declining is a normal, expected outcome of this mechanism working as intended, not a failure state that derails the whole session; treating a decline as a routine, low-cost option makes it easier to actually decline when something doesn't look right, rather than approving out of a vague worry that declining will cause more disruption than it actually does.

A final, practical reminder

If you only take one thing from this page: the appearance of this specific prompt is not noise. It is the system telling you, directly and deliberately, that this is a moment worth your genuine attention, and responding to it with genuine attention — not habit, not speed — is exactly what the mechanism was built to encourage.