> permissions & sandbox

Two layers control what the agent may do. Permission tokens in cli-config.json (Shell, Read, Write, WebFetch, Mcp) allow or deny specific actions, with deny always winning. The sandbox isolates command execution and file/network access, tunable per run with --sandbox and the path flags, or persistently through the config.

// permissions & sandbox

4 commands

// faq

How do I set permissions for the Cursor CLI?

Add tokens under permissions.allow and permissions.deny in ~/.cursor/cli-config.json (global) or <project>/.cursor/cli.json (project). Tokens look like Shell(git), Read(src/**), Write(package.json), WebFetch(docs.github.com), and Mcp(server:tool), and support globs. Deny rules take precedence over allow rules.

What is the difference between --force and permissions.allow?

--force is a blunt "allow anything not explicitly denied" switch for a single run. permissions.allow is a standing, scoped allowlist of exactly the tools and commands you trust. In CI, prefer permissions.allow so a prompt-injection cannot make the agent run arbitrary shell the way blanket --force would permit.

What does the sandbox actually restrict?

It isolates shell command execution, disables network access by default (turn it on with --network), and confines file access to the workspace unless you widen it with --allow-paths / --readonly-paths or narrow it with --blocked-patterns. Set it per run with --sandbox enabled|disabled, or persistently via sandbox.mode in the config.

How does sudo work without exposing my password to the model?

When a command needs elevation, the CLI shows a masked prompt and passes your password directly to sudo over a secure IPC channel. The AI model never sees the password — only sudo does. This lets privileged commands run without leaving the CLI.