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.