Claude Code vs Cursor: safety controls compared

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

How approvals work in each

Claude Code asks before most actions out of the box. The permissions docs 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 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 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 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 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 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, 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 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 has a tested script.

Cursor's hooks docs 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: 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, 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 when it needs real data.

None of these controls know what a command would break in your systems. That's the gap VineScale 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.