Cursor vs Claude Code vs Copilot: agent safety compared

Cursor, Claude Code, and GitHub Copilot all run tools with your account's reach — but they do not use the same defaults for auto-approval, OS sandboxing, or MCP trust. If you are choosing one agent for a team, or hardening the one you already use, the comparison that matters is not model quality. It is which commands and MCP calls can run while you are looking elsewhere.

This post compares those four controls — auto-approve behavior, sandbox boundaries, MCP defaults, and permission configuration — using vendor documentation and published research. It extends the injection surface discussion in AI agent security for coding assistants with a query-focused head-to-head, not a repeat of the skill-injection narrative.

TL;DR: what people search for

Scope: three products, more than three surfaces

Cursor is an agentic IDE. Claude Code is a terminal-first agent with first-class permission and sandbox files. GitHub Copilot spans at least three different security postures:

1. Copilot in VS Code (chat agent, terminal tools, experimental agent sandbox).
2. Copilot CLI (local OS sandbox, optional sandboxed MCP/LSP child processes).
3. Copilot coding agent on GitHub (repository MCP config, autonomous tool use in cloud).

Comparisons that treat "Copilot" as one switch are misleading. The MCP row in the table above is the clearest example: CLI docs emphasize sandboxing local MCP servers; repository MCP docs emphasize autonomous tool invocation.

Auto-approve and run modes

Cursor

Cursor documents four run modes in Run Modes. Auto-review is the recommended default as of Cursor 3.6 (May 29, 2026). For each shell, MCP, or Fetch call, Cursor checks an allowlist first, runs in the sandbox when possible, then sends remaining calls to an LLM classifier before surfacing a human approval prompt.

Run Everything is the other end of the spectrum: maximum throughput, minimum friction, and the mode closest to the "auto-approve" criticism in earlier research. Project policy lives in .cursor/permissions.json: terminalAllowlist, mcpAllowlist, and natural-language autoRun.allow_instructions / block_instructions that steer the classifier — the docs explicitly say these are not hard enforcement.

Historical context: AIShellJack evaluated Cursor v1.2.2 in Auto mode (model-routing mode, not today's Auto-review pipeline) and reported 83.4% attack success on one TypeScript scenario when rule files were poisoned. That number is a reason to configure run modes deliberately; it is not a guarantee of today's score after Auto-review shipped.

Claude Code

Claude Code expresses autonomy through permission modes (permissions):

• default — prompts according to allow/ask/deny rules.
• auto — auto-approves tool calls with background safety checks.
• dontAsk — auto-denies unless pre-approved.
• bypassPermissions — skips prompts except explicit ask rules, connector policies, and circuit breakers like rm -rf /.

Organizations can disable auto or bypassPermissions via managed settings. Auto mode adds a second layer: the autoMode classifier with hard_deny, soft_deny, and allow prose rules — but permissions.deny is evaluated before the classifier and is the deterministic floor.

Check Point's CVE-2025-59536 and CVE-2026-21852 disclosures show hook and settings injection paths that bypass the chat UX entirely — worth pairing permission mode choice with hook file hygiene.

GitHub Copilot (VS Code and CLI)

In VS Code, Manage approvals and permissions defines session permission levels. Default Approvals follows configured rules. Assisted permissions (Agent Host) adds an LLM judge that approves or escalates each tool call. Bypass Approvals and Autopilot auto-approve everything — useful for trusted sandboxes, dangerous on an open repository.

Terminal behavior is split:

• chat.tools.terminal.enableAutoApprove defaults to true (AI settings reference).
• Per-command overrides live in chat.tools.terminal.autoApprove (destructive commands like rm, curl, and wget default to requiring approval when listed).

Microsoft's agent security guidance states plainly that auto-approval rules are best-effort parsing — not a substitute for sandboxing when prompt injection is in scope.

Copilot CLI is separate: sandboxing is opt-in via /sandbox enable and persists until disabled, unless enterprise policy requires it (about cloud and local sandboxes).

AIShellJack found lower attack success rates for GitHub Copilot in VS Code than for Cursor Auto on the same scenario — but still reported substantial success (for example 41.1%–52.2% with premium models on one codebase). Auto-approve defaults explain part of the gap; they do not eliminate the class.

Sandboxing: what the OS actually enforces

Cursor

Cursor's sandbox reference defines workspace read/write or read-only modes, network allow/deny lists, and an explicit insecure_none type that disables sandboxing. Auto-review uses the sandbox when a command can be sandboxed; other platforms may skip straight to the classifier per run-mode docs.

Sandboxing is complementary to permissions: permissions.json steers which calls auto-run or get classified; sandbox.json limits what a sandboxed call can reach.

Claude Code

Claude Code's sandbox applies to Bash and child processes, enforced by the OS kernel on macOS, Linux, and WSL2 (sandboxing). It does not govern the built-in Read tool — Read/Edit path rules are a separate permission layer. When autoAllowBashIfSandboxed is true (default), sandboxed Bash can run without prompting even if a broad Bash ask rule exists, because the boundary substitutes for the prompt.

That design trades fewer clicks for a clear containment story on shell activity — aligned with the enterprise permissions lesson that filesystem rules and execution rules are different surfaces.

GitHub Copilot

VS Code: Agent sandboxing is preview, off by default (chat.agent.sandbox.enabled: off). When enabled on macOS/Linux, sandboxed terminal commands auto-approve because they are confined (approvals docs). VS Code 1.109 (January 2026) shipped experimental terminal sandbox settings under the chat.tools.terminal.sandbox.* family in release notes — check which setting names your build exposes; the AI settings reference consolidates around chat.agent.sandbox.*.

CLI: Local sandboxing is deny-by-default for paths unless granted (understanding local sandboxing). Enterprise admins can require sandboxing and sandboxMcpServers: true so MCP servers started by the CLI run inside the same policy (enterprise managed settings).

Cloud agent: Runs in GitHub's environment, not your laptop sandbox — a different trust boundary entirely.

MCP defaults: the approval gap

MCP tool descriptions are untrusted text in the agent context — see MCP security: a practical guide for poisoning classes. Client defaults determine whether one poisoned description becomes an immediate action.

Empirical work on MCP clients (Are AI-assisted Development Tools Immune to Prompt Injection?, arXiv:2603.21642) reported Cursor 1.6.45 failing several tool-poisoning scenarios in their harness (hidden parameters, priority manipulation, markdown exfiltration links) while Claude Code 2.0.25 blocked or limited several of the same tests — with the caveat that results depend on model, configuration, and permission files you actually deploy.

Permission files and repo trust

All three ecosystems push policy into the repository:

• Cursor: .cursor/permissions.json, .cursor/sandbox.json, plus rules files consumed as context.
• Claude Code: .claude/settings.json, managed settings, hooks, and CLAUDE.md.
• Copilot / VS Code: workspace settings, .github/copilot MCP manifests for cloud agents, CLI config for local sessions.

Poisoned repo content is the common thread in CVE-2025-54135 and in AIShellJack's rule-file attacks. The vibe coding security checklist item on cloning untrusted repos applies regardless of vendor.

Human approval is necessary but not sufficient

Humans miss roughly one in three risky agent commands in lab conditions — batch approvals and click fatigue are real. Vendor classifiers (Cursor Auto-review, Claude auto mode, Copilot Assisted permissions) reduce prompt volume but are still model-mediated judgments, not proofs.

Anthropic's internal assessments also note that auto-mode classifiers block many but not all dangerous tool calls in adversarial settings (alignment assessment summary). Treat classifiers as a layer, not a replacement for sandbox boundaries and least-privilege MCP tool lists.

A practical hardening order

1. Name your surface — IDE (Cursor), terminal agent (Claude Code), VS Code agent, Copilot CLI, or cloud coding agent — and read that surface's docs only.
2. Turn off bypass modes for everyday work (Run Everything, bypassPermissions, Bypass Approvals/Autopilot).
3. Enable OS sandboxing where available (Claude Code Bash sandbox, Copilot CLI /sandbox, VS Code chat.agent.sandbox.enabled) before widening auto-approve lists.
4. Treat MCP as production API access — minimal tool allowlists, especially on GitHub cloud agents; scan configs before connect per MCP security guide.
5. Keep an independent timeline — when prevention fails, you need shell and MCP evidence that does not depend on the chat log. Beam fits here as a local monitor: hook-driven capture for supported harnesses, heuristic skill/MCP scanning before run, redaction before persistence, and no blocking in v1 (what is AI agent monitoring?).

None of these steps makes prompt injection impossible. They change how much damage a poisoned README or tool description can do before a human or a boundary stops it.

Frequently asked questions

Which coding agent is safest by default?

None is safe against prompt injection by default. Copilot VS Code enables terminal auto-approve with sandbox off. Claude Code separates Read permissions from Bash sandboxing. Cursor recommends Auto-review but still ships high-autonomy modes. Safest is a configured posture on the surface you actually use, not an abstract product pick.

Do MCP tools require approval?

Cursor routes MCP through Auto-review unless allowlisted. Claude Code uses explicit MCP permission rules. GitHub cloud Copilot agents document autonomous MCP tool use after configuration. Copilot CLI can sandbox local MCP processes when sandboxing is on; remote MCP stays outside that boundary.

Does sandboxing replace human approval?

It replaces approval for commands that fit inside the sandbox boundary by design — Claude Code's auto-allow-sandboxed-Bash and VS Code's auto-approve-sandboxed-terminal pattern. Tools that read files via non-sandboxed paths, remote MCP, or explicit sandbox escapes still need rules or prompts.

What research compared these tools?

AIShellJack (arXiv:2509.22040) poisoned coding rule files against Cursor and Copilot in VS Code. The MCP client study (arXiv:2603.21642) tested tool poisoning across Claude Code, Cursor, and others. Use both to understand attack classes; re-test after you change run modes.

Where does Beam fit?

Beam records local agent activity and scans skill/MCP files before execution. It does not replace vendor sandboxes or approval UIs — see how to vibe code safely with Beam for scope limits.

Related reading

• AI agent security: securing coding assistants against skill injection — skill injection, CVEs, and defenses
• MCP security: a practical guide — tool poisoning and rug pulls
• AI agent security incidents: a timeline (2025–2026) — CurXecute and Claude Code hook CVEs in context
• Enterprise data, agents, safety, permissions, and injection — org rollout framing
• Vibe coding security checklist — nine actionable habits
• AI agent security platforms: how to evaluate one — monitors vs scanners vs enterprise enforcement
• How to stop Claude Code from running dangerous commands — permission rules, PreToolUse hooks, and sandboxing, with copy-paste config
• How to stop Cursor from running dangerous commands — the same setup for Cursor's auto-run mode
• What are agent harnesses? — the underlying concept behind every one of these permission systems

Vendor defaults and doc URLs reflect public documentation as of September 12, 2026. Research citations use the arXiv versions available at publication time; product versions in those papers are noted inline and may differ from current releases.