Permission modes and YOLO mode in Claude Code, Codex and Cursor

Permission modes decide which actions a coding agent can take on its own and which ones wait for your approval. They go from read-only, to asking before each edit or command, to running everything without a single prompt, the setting people call YOLO mode.

How permission modes work

Every time the agent wants to do something, like edit a file, run a shell command or fetch a URL, it checks whether that action is allowed. The mode sets the overall level of trust for the session. Rules refine it: “always allow npm test”, “never read .env”. Some modes add a classifier that reviews actions for you, approving routine ones and stopping risky ones.

Deny rules are the strongest layer where a tool has them. In Claude Code, Grok Build and the Cursor CLI, an action that matches a deny rule is blocked even in the most permissive mode.

The sandbox is a separate layer, and every one of these tools says so. Permissions decide whether an action runs. The sandbox limits what an approved action can reach on your filesystem and network. You can run a permissive mode inside a strict sandbox, or the other way around.

Permission modes in each tool

The names differ a lot, so here’s how they line up. None of the four docs calls a mode “YOLO mode” today, but Codex, the Cursor CLI and Grok Build all ship a --yolo flag. Claude Code’s equivalent is --dangerously-skip-permissions.

Claude Code

Claude Code has six modes. default asks the first time you use each tool. acceptEdits accepts file edits and common filesystem commands like mkdir and mv without asking. plan explores without editing your source, as described in plan mode. auto runs without routine prompts, with a background classifier checking actions like shell commands first. dontAsk denies anything that would need a prompt. bypassPermissions skips the prompts, apart from a few actions no mode approves automatically.

Shift+Tab cycles through default, acceptEdits and plan. In recent versions, interactive sessions start in auto mode. You can also start with --permission-mode, or set permissions.defaultMode in your settings.

Rules look like Tool or Tool(specifier), such as Bash(git push *) or Read(./.env), and they’re checked in order: deny, then ask, then allow. Deny rules apply in every mode, including bypassPermissions.

--dangerously-skip-permissions is the same as bypassPermissions. The docs say to use it only in isolated environments like containers, VMs or dev containers without internet access, and Claude Code refuses to run it as root. See permission modes in the Claude Code docs.

OpenAI Codex

In Codex, permissions combine two settings. The sandbox mode is read-only, workspace-write or danger-full-access. The approval policy is on-request, where Codex asks when it needs to go past the sandbox, or never.

You rarely set those two by hand. The permissions menu under the composer offers presets built from them: Ask for approval, Approve for me (an automatic reviewer handles eligible requests) and Full access. In the CLI, /permissions switches between presets like Auto and Read Only. The docs suggest starting most work with Ask for approval, which lets Codex work inside the current workspace and pauses before it goes beyond.

Full access means danger-full-access plus approval_policy = "never". The flag for it is --dangerously-bypass-approvals-and-sandbox, with --yolo as its alias, and the docs mark it not recommended. Notice that the Codex --yolo removes the sandbox too, not only the prompts.

When Codex starts in a folder, it checks for version control. Version-controlled folders start in Auto, which is workspace write with on-request approvals, and other folders start read-only. See sandboxing in the Codex docs.

Cursor

In the Cursor editor these are called Run Modes, under Settings > Agents > Approvals & Execution. Auto-review runs allowlisted calls right away, sends other shell commands to the sandbox when it can, and lets a classifier review the rest. Allowlist runs only what’s on your allowlist without asking. Run Everything runs every tool call automatically.

Agents can edit files in your workspace without approval, except configuration files. The docs are clear that Auto-review is not a security boundary, because the classifier can make mistakes.

The Cursor CLI has its own permission rules in ~/.cursor/cli-config.json or .cursor/cli.json, like Shell(git) and Read(.env*), and deny rules take precedence over allow rules. --force allows every command unless a rule denies it, and --yolo is its alias. See Run Modes in the Cursor docs.

Grok Build

Grok Build’s permissions page lists three modes. Ask is the default and prompts for anything not already allowed. Auto lets a classifier approve safe tools, though dangerous ones may still prompt. Always-approve approves every tool call, but deny rules and PreToolUse hooks still apply.

Shift+Tab cycles from normal mode through plan, auto (when the feature is on) and always-approve. /always-approve, Ctrl+O and grok --always-approve toggle that last one, and --yolo is an alias for the flag.

There’s no read-only mode. Plan mode rejects edit tools until you approve the plan, but shell commands keep following the permission mode, so they can still write files.

Your default mode goes in your user config, ~/.grok/config.toml, not in a project’s config, so a repo you clone can’t switch it for you. Rules go under [permission], and a deny always wins over an allow. A remembered “always allow” still prompts for dangerous patterns like rm and git push. See permissions in the Grok Build docs.

Details checked against each vendor’s documentation in October 2026.

A real example

Let’s set up Claude Code so it can work through a long task, like fixing every lint error in a project, without stopping on every command. Lint and tests run freely, pushing asks first, and the .env files stay off limits. Put this in .claude/settings.json:

{
  "permissions": {
    "allow": ["Bash(npm run lint)", "Bash(npm test)"],
    "ask": ["Bash(git push *)"],
    "deny": ["Read(./.env)", "Read(./.env.local)"]
  }
}

Then switch to acceptEdits with Shift+Tab. File edits go through, lint and tests run, and git push still stops for you. The deny rules hold even if you later switch to bypassPermissions.

Grok Build takes the same idea in ~/.grok/config.toml:

[permission]
rules = [
  { action = "allow", tool = "bash", pattern = "npm run lint" },
  { action = "allow", tool = "bash", pattern = "npm test" },
  { action = "deny", tool = "bash", pattern = "rm -rf *" },
]

Codex works differently. Instead of listing commands, you pick how far the sandbox reaches. This config.toml keeps edits inside the workspace and asks before going further:

approval_policy = "on-request"
sandbox_mode = "workspace-write"

Which mode to use

Ask before acting when the repo or the task is new to you, and for anything that touches production, credentials or money.

Accept edits when you review the diff in Git anyway. A bad edit is one git restore away. A bad command often isn’t, so keep commands on rules.

Use a classifier mode for long tasks where prompts would break your focus, as long as you accept that it can misjudge. Claude Code’s docs say auto mode reduces prompts but doesn’t guarantee safety.

Skip all prompts only where a mistake can’t hurt you: a container, a VM or a throwaway cloud machine. That’s the isolation Claude Code’s docs ask for before you use bypassPermissions.

Pitfalls

YOLO flags don’t all skip the same thing. In Codex, --yolo also turns off the sandbox. In Grok Build it’s always-approve, and the sandbox stays as configured.

No prompts means no protection against prompt injection. The Claude Code docs say bypassPermissions offers none against prompt injection or unintended actions. It also skips the prompts for writes to protected paths like .git and .claude.

Allowlists are a convenience. Cursor’s docs describe allowlists and auto-run instructions as best-effort, not a security boundary. Use deny rules and a sandbox for anything you can’t afford to lose.

Scripts behave differently. The Cursor CLI has full write access in non-interactive mode, and in a non-interactive Codex run, an action that needs new approval fails instead of waiting for you.

Modes spread to helpers. Subagents in Codex and Grok Build inherit the parent’s permissions, so delegating doesn’t make a task safer.

Related on flaviocopes.com

• Things I let coding agents do unattended, and things I never do goes task by task through what I hand over and the guardrail for each.
• How to prevent AI agents from taking irreversible actions covers confirmation steps that don’t depend on the agent’s goodwill.
• How to protect secrets when coding agents deploy your app deals with the .env files and tokens deny rules should cover.
• How to let coding agents test Mac apps in a VM keeps an agent’s clicks inside a virtual machine instead of on your screen, and VM Peek, my Mac app, shows every command the agents ran in there.

Related glossary entries

• Plan mode: Plan mode makes a coding agent research and propose a plan before it edits code. How it works in Claude Code, Codex, Cursor and Grok Build, and when to use it.
• Hooks: Hooks run your own scripts when a coding agent calls a tool or stops. How hooks work in Claude Code, Codex, Cursor and Grok Build, with examples.
• Subagents: A subagent is a helper your coding agent starts with its own context window. How subagents work in Claude Code, Codex, Cursor and Grok Build.

All AI glossary entries →

Want me to talk about your product? You can sponsor this site.