Blog
Cursor CLI --force and --yolo: Run Everything, and the middle mode worth using
Cursor's CLI has three run modes and most people only know two of them. The one in the middle is the one that makes running without prompts reasonable.
In Cursor CLI, --force (alias --yolo) approves every command the agent wants to run, which Cursor calls Run Everything. It does not disable the sandbox, which is a separate --sandbox switch, and Cursor's middle mode, Auto-Run in Sandbox, approves everything as long as it runs inside that sandbox with network denied by default. That middle mode is the one for unattended work. Forkbench covers the part Cursor itself calls best effort: a key used through Vault never enters the agent's environment.
The three modes
Cursor shipped three named run modes for its CLI in January 2026. Ask Every Time is the default and does what it says. Run Everything approves every command, and is what --force, -f and, since February 2026, --yolo select. Auto-Run in Sandbox sits between them.
In a session, /auto-run and Shift+Tab move between them. In a script, --force is the usual way to stop the agent from waiting for a keypress that will never come.
The CLI kept the name yolo even after the Cursor editor renamed its own YOLO mode to Auto-Run, which is why the two products use different words for related things.
Why the middle mode is the useful one
Auto-Run in Sandbox approves every command without asking, provided it runs inside Cursor's sandbox. On macOS that sandbox is Seatbelt, and its network policy defaults to deny, with an allow list you write in ~/.cursor/sandbox.json.
That is the trade most people wanted when they reached for --yolo: no clicking, and a wall that still holds when the agent is wrong. A command that tries to write outside the project, or fetch something it was not allowed to, fails without anyone needing to be there.
--force and --sandbox are documented as separate options, so you can run everything and keep the sandbox on. What you lose with plain Run Everything is the condition that keeps it there.
Allow and deny rules still apply
Below the modes is a finer layer. ~/.cursor/cli-config.json, or .cursor/cli.json in a project, takes permissions.allow and permissions.deny entries such as Shell(git), Read(glob), Write(glob), WebFetch(domain) and Mcp(server:tool).
Deny always wins. A deny rule on Shell(rm) or Write(.env) holds under --force, which makes a short deny list the cheapest protection to add before running without prompts.
Cursor is candid about the limits of all this. Its own security documentation calls these guardrails best effort rather than a hard security boundary, and says the agent's protections should not be treated as one.
How this works in Forkbench
Forkbench is a desktop app for running coding agents, and Cursor CLI is one it connects in one click. It runs the agent binary you installed with your cli-config.json and your sandbox.json untouched.
What it adds sits on the side Cursor describes as best effort. A key in Vault is used by the command that needs it without the value reaching the agent's environment, prompt or transcript, so a Run Everything session has no token in reach to send. A Thread can also be locked to a set of folders at the kernel, inherited by every process the agent starts, and each session can take its own git worktree so a bad edit lands on a branch you can delete.
The limit: a command you let run can still print what it was handed, and a key bound to a destination can still be used against that destination. That is containment, and we call it that.
Related: Yolo mode in every coding agent, compared, Cursor CLI in Forkbench, Claude Code: what --dangerously-skip-permissions actually skips
Frequently asked
What does cursor-agent --yolo do?
It is an alias for --force, which selects Run Everything: every command the agent proposes is approved without asking. It does not turn off the sandbox, which is controlled separately with --sandbox.
What is Auto-Run in Sandbox in Cursor CLI?
The middle run mode. Commands are approved automatically as long as they run inside Cursor's sandbox, which denies network by default and confines writes to the project. It is the mode built for unattended work.
Do Cursor CLI deny rules work with --force?
Yes. Deny rules in cli-config.json or .cursor/cli.json take precedence over everything else, including --force. A deny on a dangerous command or on writing a secrets file still holds when everything else is approved.
Is the Cursor CLI sandbox a security boundary?
Cursor's own documentation says to treat it as best effort rather than a hard boundary. It is a strong default and well worth having on, but credentials are better kept out of the agent's environment entirely than relied on a sandbox to contain (see Forkbench security).
How do I run Cursor CLI headless without prompts?
Pass --force (or --yolo) so the agent does not wait for approvals, and add --sandbox enabled if you want the run contained. In headless runs, --trust skips the workspace trust prompt and --approve-mcps approves MCP servers.