Every major AI coding agent's permission model, compared — and the three gaps none of them close

Jaume Roig — Thu, 16 Jul 2026 12:28:24 +0000

2026 has been the year coding agents started deleting things that matter. A Hacker News thread titled "Claude CLI deleted my home directory and wiped my Mac" hit 255 points and 216 comments. Cursor "went rogue in YOLO mode" and deleted itself along with everything else. On OpenAI's forum, users reported Codex executing file deletions outside the project directory — 240 to 700 GB gone, straight past the Recycle Bin. One GitHub issue documents ~328,000 files deleted during a cleanup gone wrong, unlogged.

I run several of these agents daily, and I don't inherently trust default permissions. When they started executing shell commands on my machine, I spent the last few days dissecting the security models of all six major clients — Claude Code, Cursor, Codex CLI, VS Code Copilot, Claude Desktop, and Devin Desktop — to answer one question: when your agent tries something dangerous, what actually stands in the way?

The answer surprised me twice. First, because the native protections are better than most people think. Second, because all six share the same three gaps.

The good news first: native protections are real

Credit where it's due — the vendors have been busy:

	Per-call approval	Rules on MCP tool arguments	Sanitize tool outputs	OS sandbox	Hooks
Claude Code	✓	✗ (tool name only)	via hooks	✓	✓
Cursor	✓	✗ (`server:tool` only)	via hooks (MCP only)	✓ default-on	✓ — but fail-open
Codex CLI	✓	✗	✗	✓	✗
VS Code Copilot	✓	✗ (regex engine is terminal-only)	✗	✓ default-on since v1.127	✓ preview — can't rewrite
Claude Desktop	✓	✗	✗	✗ — MCP servers run with your user permissions	✗
Devin Desktop	✓	✗ (word-boundary prefixes)	✗	✓ (Devin Local)	✗

Cursor runs non-allowlisted shell commands in a Seatbelt/Landlock sandbox by default. Codex ships three sandbox levels and per-tool MCP approval modes. VS Code turned on kernel-level sandboxing for terminal commands by default two weeks ago (v1.127). And it's worth being honest about the horror stories above: the worst ones happened after the user turned the protections off — the Codex data-loss reports were in danger-full-access mode, which is exactly what its name says.

So no, the problem is not "agents have no brakes." The problem is where the brakes stop working. Three gaps, consistent across all six clients.

Gap 1: nobody can write rules against the arguments of an MCP tool call

VS Code has a genuinely good allow/deny engine — regex against full command lines, deny-overrides-allow. But it only applies to the integrated terminal. For MCP tools, approval is binary: trust the tool or don't.

The same pattern repeats everywhere. Cursor's MCP allowlist matches server:tool strings — no arguments. Codex approves by tool name and annotation. Claude Desktop offers "Allow always" per tool and nothing finer. Claude Code's permission rules match MCP tools by name only. Devin Local matches word-boundary prefixes, no regex.

Put simply: you can block rm -rf in VS Code's terminal — but not inside an MCP tool call, in any client. And the MCP tool call is exactly where a poisoned README or a malicious tool description turns your agent into the attacker. The agent doesn't need your terminal if a run_command tool is mounted.

Gap 2: nobody sanitizes what tools return

Everyone watches what the agent tries to do. Almost nothing watches what the agent reads. Tool results are the front door for indirect prompt injection — a fetched webpage, a repo file, a database row that says "ignore previous instructions and…" — and they enter the model's context unfiltered in every client, by default.

Native output sanitization across the six clients: zero. Claude Code and Cursor can do it via hooks (updatedToolOutput / updated_mcp_tool_output) — if you write those hooks yourself. The other four have no mechanism at all. Claude Desktop's Cowork mode reviews actions with a model-based safety check, which is better than nothing but non-configurable and non-deterministic.

The MCP spec itself is upfront about this: "MCP itself cannot enforce these security principles at the protocol level." Enforcement is the host's job — and the hosts, today, mostly don't.

Gap 3: the allowlists aren't security boundaries — the vendors say so themselves

This is the part I'd want every agent user to read twice, because it's stated in the vendors' own documentation.

Cursor, verbatim: "Not a security boundary. Allowlists and autoRun instructions are best-effort convenience. They are not a security guarantee."

Microsoft, verbatim: "best-effort command parsing that has known limitations. For example, quote concatenation or shell aliases might bypass the rules."

These aren't hypothetical caveats. Cursor's prefix allowlist was bypassed in the wild with simple && chaining (allowlist cd, then cd x && terraform apply -auto-approve sails through). CVE-2026-22708 — patched in Cursor 2.3 — let shell built-ins and environment-variable poisoning execute without appearing in the allowlist at all.

Even the newest mitigation — Cursor's Auto-review mode — is a classifier subagent: a model deciding whether another model's action looks safe. Useful, but probabilistic. When the stakes are rm -rf, "usually catches it" is a strange guarantee.

Six clients, six models — and the multi-agent hub doesn't save you

If you run more than one agent — and most of us now do — you're maintaining a different security model per client, with different config formats, different capabilities, and different failure modes.

You might hope the new multi-agent hubs fix this. They don't. Devin Desktop (the June rebrand of Windsurf) runs third-party agents like Codex and Claude Agent via the Agent Client Protocol — and its docs state plainly: "all agent operations are delegated to the agent." The hub displays whatever permission prompts each agent chooses to send. Security stays heterogeneous; the hub unifies the UI, not the policy.

Meanwhile the landscape churns under your configs: Windsurf became Devin Desktop, Continue.dev is winding down, Cursor is being acquired. Every migration is a security config you rewrite — or forget to.

(One telling detail: VS Code's new hooks system reads Claude Code's .claude/settings.json format. Even the vendors are tired of N incompatible configs.)

"Just write hooks" — sure, and here's the bill

Hooks are the standard power-user answer. If you live in a single client and enjoy writing bash, hooks will take you far. Claude Code and Cursor hooks can block a call, rewrite arguments, and scrub a tool's output before the model reads it.

But as a security mechanism, hooks are fragile and fragmented. First, three major clients have no hooks at all (Codex CLI, Claude Desktop, Devin Desktop). Second, the ones that do exist are inconsistent: VS Code's hooks can't rewrite anything.

The biggest red flag? Cursor's hooks fail open by default. If your bash script crashes, times out, or has a syntax error, the dangerous action goes through. In security, a firewall that fails open isn't a firewall — it's a suggestion. And even if you write perfect scripts, you are still maintaining them per project, per client, forever.

What an inline proxy does differently

Disclosure: I built the tool below to scratch my own itch, so read this section knowing that.

The gaps we just talked about all share the same structural flaw: enforcement lives inside the client. This means security is only as good — and as consistent — as each individual client's implementation.

I got tired of maintaining five different fragmented configs, so I decided to move enforcement below the clients, directly into the MCP connection itself.

That's why I built MCP-Shield. It's a local proxy that sits inline on the JSON-RPC wire between any MCP client and its servers. The philosophy is simple:

One policy to rule them all. Write the rules once, and they apply instantly whether the call comes from Claude Code, Cursor, Codex, VS Code, or anything else speaking MCP.
Argument-level rules on MCP tool calls — the glaring hole none of the six clients close natively (Gap 1).
Output sanitization before dirty data reaches the model's context window (Gap 2).
Deterministic, fail-closed enforcement. It uses hard rules, not probabilistic classifiers. If it breaks, it denies access. (Gap 3).
A live local dashboard to review, approve, deny, or even edit a held call on the fly before it executes.
Because it inspects the raw wire, it catches tricks that native hooks structurally can't even see (like duplicate-key parser differentials and batch smuggling).

The goal was zero friction. You don't have to touch your existing client configs, the installer handles the wiring:

npm install -g @jrooig/mcpshield
mcp-shield install

What it doesn't do

Let's be completely honest: MCP-Shield is a scalpel, not a magic bullet. It only intercepts MCP traffic. If an agent uses its built-in terminal or native file-editing capabilities, MCP-Shield won't see it. (That's what native OS sandboxes are for — use both.)

The prebuilt rules cover the most common destructive patterns, but it's not a catch-all — you are expected to read and extend them for your own workflow. And obviously, no software in the world can fix the human error of blindly clicking "Approve" without reading the prompt. It's an extra layer of defense-in-depth, not a free pass to turn your brain off.

Where this leaves us

To give credit where it's due, vendors are taking this seriously and building real brakes — VS Code's default-on kernel sandbox is barely two weeks old and it's a massive step forward.

But until the architecture changes, the three gaps remain structural. As long as enforcement is handled per-client, we're stuck with argument-blind MCP approvals, unfiltered tool outputs, and N different configs that explicitly admit they are not security boundaries.

The agents went cross-client a long time ago. The attacks are cross-client now. It's time our security layer became cross-client too.

If you want to poke holes in the code or use it yourself, MCP-Shield is open source (MIT): github.com/jaumerohi2007-cell/mcp-shield · mcp-shield.dev

DEV Community: Jaume Roig