ConsLabs
Claude Code
Fundamentals3 min read

Permission Modes

How Claude Code's permission system works, the different modes available, and how to tune it per command or tool.

Claude Code can run real, consequential commands — installing packages, deleting files, pushing to a remote, modifying a database schema. The permission system exists to put a human decision point in front of anything that crosses from "thinking" into "doing," at whatever granularity you choose.

The default behavior

Read-only actions — reading a file, searching the codebase, listing a directory — generally run without asking, since there's nothing to confirm: nothing changes as a result. Actions with side effects — editing or creating a file, running a shell command — prompt for approval the first time they're needed in a session, and you choose at that moment whether to approve once, approve for the rest of the session, or deny.

Tuning it further

Beyond the basic ask-or-don't-ask choice, permissions can be scoped more precisely: an allowlist of specific commands (a particular test runner, a specific lint command) that run automatically, while anything outside that list still asks. This is the practical middle ground for most real work — full manual approval is safe but slow if you're confirming the same lint command forty times a session; full automatic approval is fast but means you're not actually reviewing anything before it happens.

A reasonable starting allowlist for a typical project includes the test command, the linter, and read-only git commands (status, diff, log) — none of which can cause damage even if Claude gets something wrong — while leaving destructive commands (rm, force-push, database migrations) gated behind explicit approval indefinitely.

Full autonomy mode

There's also a mode that approves everything without asking — useful for unattended runs (a CI job, a background batch of small fixes) where no one is available to respond to prompts, but worth treating as a deliberate, scoped choice rather than a default. It removes the human checkpoint entirely, so it's most appropriate for low-stakes, well-tested tasks, sandboxed environments, or situations where the blast radius of a mistake is small and recoverable.

How this relates to plan mode

Permission modes control whether an individual action needs approval. Plan mode is a different, complementary control: it asks for approval of the overall approach before any actions happen at all, which matters most for ambiguous or multi-step work where the risk isn't any single command but the cumulative direction of many of them. You can combine the two — plan mode for the upfront approach, then a permissive allowlist for the individual steps once the plan itself is approved.

A practical rule of thumb

Match the permission posture to two things: how reversible a mistake would be, and how well-tested the codebase's safety nets are (a strong test suite makes automatic approval much safer than a codebase with no tests at all). Unfamiliar codebase, weak tests, or anything touching production-adjacent systems: stay conservative. Familiar codebase, strong tests, low-stakes changes: loosen it and let the agent move at full speed.

With setup covered, the next section moves into what Claude Code can actually do — starting with reading and editing files.