# Autonomy Level Choose Off, Low, Medium, or High to control what Droid can do without repeated confirmations. Autonomy Level sets the highest-risk work Droid can run without pausing for approval. It is separate from interaction mode: Normal Mode executes work, while Spec Mode plans before implementation. ## Choose a level Execute commands and MCP tools have a risk level (`low`, `medium`, or `high`). For shell commands, [permission rules](/autonomy-and-safety/permission-rules) can allow execution, require approval, or block execution before autonomy fallback. Commands with no policy match run automatically when their risk is at or below your Autonomy Level. Sandbox checks can require separate approval. | Autonomy Level | What can run without approval | Examples | | -------------- | ------------------------------------------------------- | ---------------------------------------------------------------------- | | **Off** | Built-in read tools and commands allowed by policy | `Read`, `LS`, `ls`, `pwd`, `git status` | | **Low** | File edits plus low-risk commands and MCP tools | `Edit`, `Create`, `rg`, showing logs | | **Medium** | Everything from Low plus reversible workspace changes | `npm install`, `pip install`, `git commit`, `mv`, `cp`, build tooling | | **High** | High-risk actions unless safety checks require approval | `docker compose up`, `git push` if allowed, migrations, custom scripts | Droid still streams output and highlights file changes at every level. ## How approvals work Autonomy Level controls automatic approval, not which tools are available. Tool policy, MCP configuration, model support, and organization controls can still restrict tools. {/* sweep-allow: term-bullets */} - **Normal vs. Spec Mode**: In Normal Mode, Autonomy Level controls approvals. Spec Mode is read-only planning; after approval, Droid exits Spec Mode and returns to Normal Mode for implementation. - **File changes**: Low or higher lets Droid create, edit, and patch files without asking first. - **Commands and MCP tools**: Droid compares the tool risk level to your Autonomy Level. If the risk is higher, it asks before continuing. - **Command policy**: An effective `allow` skips command approval, `ask` requires it even at High, and `block` rejects the command with no approval path. Deprecated command lists still participate for backward compatibility. - **Safety checks**: Built-in runtime safeguards can require approval for recognized destructive operations. [Sandbox](/autonomy-and-safety/sandbox) read, write, and network checks can also prompt separately. An allow rule grants permission; it does not prove a command is read-only. - **Allow always**: Choosing an "always allow" option raises the current Autonomy Level to the level required by that prompt. Sandbox "allow always" options instead persist the allowed path or domain. - **Spec approval**: When approving a Spec Mode plan, choose **Proceed with implementation** to continue with manual approvals, or choose an available Low, Medium, or High option for implementation. Organization Maximum Autonomy Level can hide higher options. ## Permission rules Use `permissionRules` in [Settings](/droid-cli/settings#permission-rules) for new command policy. Rules match exact, ordered command arguments and include positive and negative examples. See [Permission rules](/autonomy-and-safety/permission-rules) to create, test, and preview them. After rule IDs are resolved across settings sources, matching blocks take precedence over requests for approval, which take precedence over allows. Commands with no match fall back to session approvals and the active Autonomy Level. Organization and project definitions with the same ID follow [rule source precedence](/autonomy-and-safety/permission-rules#understand-scope-and-precedence). `--skip-permissions-unsafe` skips all permission prompts, but command blocks still apply. ## Command allowlists, denylists, and blocklists `commandAllowlist`, `commandDenylist`, and `commandBlocklist` are **deprecated, not removed**. Existing lists remain respected for backward compatibility. Use `permissionRules` for new configuration; immediate migration is not required. The replacement decisions are `allow`, `ask`, and `block`, respectively. A native rule can replace a custom legacy restriction from the same settings source, while restrictions from other sources remain effective. Review [migration and coexistence](/autonomy-and-safety/permission-rules#migrate-legacy-command-lists) before changing existing policy. Command rules are not operating-system isolation. Prefixes do not cover every equivalent command spelling or inspect arbitrary script behavior. Use [sandboxing](/autonomy-and-safety/sandbox), managed hooks, and least-privilege credentials for additional protection. ## Change the level - Press to cycle `Off → Low → Medium → High → Off`. Organization policy can cap the highest available level. - Press to switch between Normal Mode and Spec Mode. - Set a default in `/settings` for future sessions. - Change Autonomy Level before implementation, from the [Spec Mode](/autonomy-and-safety/specification-mode) approval dialog, or any time after leaving Spec Mode. ## Where Autonomy Level applies {/* sweep-allow: term-bullets */} - **Interactive CLI**: `droid` uses the session's current Autonomy Level. `droid ""` starts the same interactive CLI with an initial prompt, so the first task uses your configured default. See the [CLI reference](/droid-cli/cli-reference). - **Factory App**: Factory App sessions use the same Normal, Spec, Mission, and Autonomy Level controls as CLI sessions. - **Droid Exec**: `droid exec` is read-only by default. Use `--auto low`, `--auto medium`, or `--auto high` for non-interactive runs that need edits, local development commands, or broader automation. See [Droid Exec](/droid-exec/overview). - **Custom Droids (Subagents)**: Task-launched subagents inherit the parent session's Autonomy Level by default, or use the **Subagent autonomy level** setting (`inherit`, `off`, `low`, `medium`, `high`) when configured, always clamped to the organization's Maximum Autonomy Level. In Spec Mode they are read-only. Organization and Droid tool policy can still restrict them. See [Custom Droids](/harness/subagents). - **Factory Missions**: Missions orchestration requires High autonomy or `--skip-permissions-unsafe` (unsafe: skips permission prompts, but not effective command blocks; use only in isolated sandboxes), and admins can restrict who can start Missions. See [Factory Missions](/missions/overview). ## Enterprise Controls Enterprise admins can set organization-wide autonomy boundaries with organization-managed settings. See [Enterprise Controls & Managed Settings](/enterprise/hierarchical-settings-and-org-control). - **Default Autonomy Level** sets the starting level for new sessions. - **Maximum Autonomy Level** caps how high members can raise autonomy. If the maximum is Medium, High is unavailable in the CLI. These controls layer with permission rules, legacy command lists, MCP restrictions, sandbox settings, and Missions access controls. ## Use it safely - Start new or high-stakes work with Off or Low until you trust the plan. - Match the minimum level to the work: use Low for file edits and generated reports, Medium when the run must install dependencies, build, test, or make local commits, and High for pushes, deployments, Task-launched subagents, Missions, or other orchestration. - Add defense in depth with [blocking hooks](/harness/hooks), permission rules, MCP restrictions, least-privilege credentials, and isolated runners. - For CI workflows, choose the lowest `droid exec --auto` level that allows the workflow to complete. See [Automated Code Review](/software-factory/code-review-ci) and [Droid Exec](/droid-exec/overview). - If you spot a suspect command, interrupt, provide guidance, and resume at the Autonomy Level that fits the remaining risk. Understand Normal, Spec, and Mission Mode and how they relate to autonomy. Enforce deterministic policy and validation at every tool call. Define and test command approval policy. Add filesystem and network isolation.