# Claude Code vs Cursor: safety controls compared

> How Claude Code and Cursor handle approvals, allow and deny rules, sandboxing, hooks and team policy, side by side and checked against both vendors' docs.

Web page: https://vinescale.com/blog/claude-code-vs-cursor-safety/
By Gary Mathis, founder of VineScale (https://vinescale.com/about/). Published 2026-11-01.

In the Claude Code vs Cursor comparison for safety, the two agents have converged on the same layers: an approval mode, rules about what may run without asking, an operating-system sandbox for shell commands, hooks that can block a call, and settings an organization can lock. The differences are in the details. Claude Code has hard **deny rules** that win in every mode, including bypass. Cursor has **allowlists** plus an AI classifier you steer with plain-English instructions, and no deny list outside hooks. Both vendors say plainly that their command matching and classifiers are not security boundaries.

This covers safety controls only, not features or price, checked against both vendors' docs on November 1, 2026. Both tools change monthly, so check the linked pages before you rely on a setting name.

## Claude Code vs Cursor at a glance

| Control | Claude Code | Cursor |
|---|---|---|
| Approval modes | Manual (`default`), `acceptEdits`, `plan`, `auto`, `dontAsk`, `bypassPermissions` | Auto-review, Allowlist, Run Everything |
| Run without asking | `allow` rules | `terminalAllowlist` and `mcpAllowlist` |
| Never run | `deny` rules, which win in every mode | No deny list; hooks can deny |
| AI review of actions | Auto mode classifier | Auto-review classifier |
| Shell sandbox | Seatbelt on macOS, bubblewrap on Linux and WSL2; off by default | Seatbelt on macOS, Landlock or Bubblewrap on Linux; used by Auto-review |
| Pre-action hooks | `PreToolUse` and more, block with exit code 2 | `beforeShellExecution`, `beforeMCPExecution`, `preToolUse` and more, block with exit code 2 |
| Organization lock | Managed settings files, MDM or the admin console | Team dashboard, Enterprise MDM hooks |

## How approvals work in each

**Claude Code** asks before most actions out of the box. The [permissions docs](https://code.claude.com/docs/en/permissions) say Bash commands need approval except "a built-in set of read-only commands" such as `ls`, `cat` and `grep`, and file edits need approval too. You switch between [permission modes](https://code.claude.com/docs/en/permission-modes) with Shift+Tab or a setting. `acceptEdits` stops asking about file edits in the working directory, `plan` lets Claude read and explore but not edit your source files, and `bypassPermissions` "skips permission prompts, except for the actions no mode auto-approves." The permission modes page also says that in recent versions auto mode is the built-in starting mode for interactive sessions, so check which mode you're in rather than assuming Manual.

**Cursor** picks a run mode in Settings, under Agents, then Approvals & Execution. The [run modes docs](https://cursor.com/docs/agent/security/run-modes) describe three:

- **Auto-review**: "Allowlisted calls run immediately. Other shell commands run in the sandbox when possible. Calls that do not use the sandbox go to the Auto-review classifier."
- **Allowlist**: only what's on your allowlist runs without approval.
- **Run Everything**: "Every tool call runs automatically."

Cursor calls Auto-review "the safest useful setup for most people." If you want to approve every command yourself, Allowlist mode with an empty allowlist does that.

Cursor also has three switches that force approval even in a mode that would otherwise run on its own: File-Deletion Protection ("including `rm` commands"), External-File Protection for files outside the workspace, and Browser Protection. On file edits, Cursor's [agent security page](https://cursor.com/docs/agent/security) says "Agents can modify workspace files without approval, except for configuration files." That is a real difference from Claude Code, where edits ask by default.

## Allow and deny rules: the biggest difference

Claude Code has three rule lists, `allow`, `ask` and `deny`, in `settings.json`. The docs say: "Rules are evaluated in order: deny, then ask, then allow. The first match in that order determines the outcome." Deny rules still block in `bypassPermissions`, and "an allow rule can't carve an exception out of a deny rule." That makes a deny rule the one place to write "never run this, whatever mode someone picks."

Cursor's [permissions.json](https://cursor.com/docs/reference/permissions) has `terminalAllowlist` (command prefixes, so `git` matches `git status` but not `gitk`), `mcpAllowlist` (`server:tool` entries) and `autoRun`, which holds `allow_instructions` and `block_instructions`. Those instructions are plain-English sentences that steer the Auto-review classifier. Cursor's docs call them "best-effort convenience" and say "They are not a security guarantee." There's no hard block list in permissions.json; to refuse a command outright, you use a hook.

Both vendors warn against reading too much into command matching. Claude Code's docs say a Bash rule "covers the invocation Claude usually produces and isn't a security boundary around the program": `Bash(curl *)` stops `curl https://example.com` but not `/usr/bin/curl` or `sh -c 'curl ...'`. Cursor says "Auto-review is not a security boundary" and "The classifier can make mistakes." Claude Code says the same of its own classifier: auto mode "reduces permission prompts but does not guarantee safety."

## Sandboxing: what each one actually enforces

Both sandboxes work at the operating-system level, so they catch what text matching misses.

Claude Code's [sandbox](https://code.claude.com/docs/en/sandboxing) uses Seatbelt on macOS and bubblewrap on Linux and WSL2. On native Windows, commands run unsandboxed. "The sandbox is off by default"; turn it on with `/sandbox` or `"sandbox": { "enabled": true }`. Writes are limited to the working directory, a temp directory and folders you add, and network traffic goes through a proxy whose allowed domains "start empty." Two limits to know: reads are allowed across "most of the machine, including credential files such as `~/.ssh` and `~/.aws/credentials`", and the sandbox "covers shell commands only. Claude's file tools, MCP servers, and hooks run outside it." If the sandbox can't start, Claude Code runs commands without it unless you set `sandbox.failIfUnavailable`.

Cursor's sandbox, configured in [sandbox.json](https://cursor.com/docs/reference/sandbox), uses Seatbelt on macOS and Landlock, with a Bubblewrap fallback, on Linux. The docs read for this article cover macOS and Linux only. Network is "blocked by default, then opened by your network mode and sandbox.json", and some paths, such as `.git/hooks`, `.vscode` and `.cursor/*.json`, stay write-protected whatever the file says. Reads default to the whole system unless you set `readBoundary` to `"workspace"`. The sandbox is built into Auto-review and optional in Allowlist mode.

## Hooks: a code-level gate in both

Both tools run your scripts before an action and let them block it by exiting with code 2.

Claude Code's [hooks reference](https://code.claude.com/docs/en/hooks) lists over 30 events. `PreToolUse` is the one that blocks: exit 2, or print JSON with `"permissionDecision": "deny"`. Our guide to [stopping Claude Code from running destructive commands](https://vinescale.com/blog/stop-claude-code-destructive-commands/) has a tested script.

Cursor's [hooks docs](https://cursor.com/docs/hooks) include `beforeShellExecution`, `beforeMCPExecution`, `beforeReadFile` and `preToolUse`. A hook returns `"permission": "allow"`, `"deny"` or, for shell and MCP hooks, `"ask"`. When several hooks answer, "any `deny` wins over `ask`, and `ask` wins over `allow`, regardless of source."

The catch is the same in both: a hook that fails doesn't block by default. In Cursor, a crash or an unexpected exit code means the action proceeds ("fail-open by default") unless the hook sets `failClosed`. Claude Code treats other non-zero exit codes as non-blocking errors and says "don't count on a stalled hook to act as a gate"; an `onFailure` setting can make a failure block. Test your hooks.

## Team policy and managed settings

**Claude Code** uses [managed settings](https://code.claude.com/docs/en/managed-settings): a `managed-settings.json` file in a system folder (for example `/etc/claude-code/managed-settings.json` on Linux), a macOS configuration profile, a Windows policy registry key, or settings pushed from the Claude admin console. They sit above every other level, so users can't override them. Keys worth knowing: `permissions.disableBypassPermissionsMode` set to `"disable"`, `allowManagedPermissionRulesOnly`, `allowManagedHooksOnly`, and `disableAutoMode` to remove auto mode.

**Cursor** puts team controls in its web dashboard. Per the run modes docs, "Admins can override which modes are available for their users, configure the sandbox networking rules for terminal commands, set a team read policy, and more," and "Team settings take precedence over individual and project configuration." For permissions.json, the order is "team admin (dashboard) > permissions.json (per-user ∪ per-repo) > IDE settings UI." Enterprise hooks can be deployed by MDM as a system-level `hooks.json`.

## Which is safer, Claude Code or Cursor?

Neither, on its own. Configured carefully, both give you approvals, an OS sandbox, blocking hooks and an organization-level lock. The practical differences:

- If you want rules that can't be bypassed by a mode change, Claude Code's deny rules are the stronger primitive. In Cursor, the equivalent is a hook with `failClosed`.
- If you want fewer prompts with a sandbox doing the work, Cursor's Auto-review puts the sandbox in the default path. In Claude Code you turn the sandbox on yourself.
- File edits ask by default in Claude Code and don't in Cursor, apart from configuration files.
- Neither sandbox stops a command from using credentials it can reach. If the shell can see a production `DATABASE_URL` or cloud token, so can the agent in either tool. Several public incidents with both agents, in our [roundup of AI coding agent incidents](https://vinescale.com/blog/ai-coding-agent-incidents/), came down to a credential in reach.

So whichever you use, keep production credentials out of the agent's environment and give it a [read-only database role](https://vinescale.com/blog/ai-agent-read-only-database-access/) when it needs real data.

None of these controls know what a command would break in your systems. That's the gap [VineScale](https://vinescale.com/beta/) is built for: a free beta gate for Claude Code, with beta support for Cursor, that works out what an action would touch in production and lets it through, asks or blocks it. In Cursor, for some actions where the gate would ask, it blocks the step and hands it to you instead, because it can't stop to ask there.

## Frequently asked questions

### Does Cursor have deny rules like Claude Code?

Not in permissions.json. Cursor's permissions file has allowlists for terminal commands and MCP tools, plus `block_instructions`, which are plain-English guidance for the Auto-review classifier that Cursor says are "not a security guarantee." To block a command outright in Cursor, use a `beforeShellExecution` hook that returns `"permission": "deny"` or exits with code 2.

### Is Cursor's Auto-review the same as Claude Code's auto mode?

They are similar ideas: both send actions that aren't pre-approved to a separate classifier model that decides whether they run, and both vendors say that classifier can be wrong. The difference is that Cursor's Auto-review runs shell commands in its sandbox first when it can, while Claude Code's sandbox is a separate setting you turn on.

### Can a team stop developers from turning off the safety settings?

Yes, in both. Claude Code's managed settings override every user and project setting and can disable bypass mode, auto mode and non-managed hooks or permission rules. Cursor's team dashboard settings take precedence over individual and project configuration, and admins can limit which run modes are available.

VineScale is a safety gate for AI coding agents. The gate for Claude Code is in free beta, with beta support for Codex, Cursor, Antigravity and Grok Build: https://vinescale.com/beta/