"It can read files, edit code, and run commands" is the sentence that makes most new users nervous — and the permission model is the actual answer to that nervousness, not a footnote to it. Here's what really gets pre-approved, what needs your review, and what deserves a closer look even within the normal review step.
Read-only exploration — looking at files, searching the codebase, understanding structure — happens without asking, the same way you'd expect a colleague to look before touching anything. Nothing gets written, deleted, or executed at this stage. This is also usually the largest share of what happens in a session, even though it's the part you notice least.
File edits and shell commands are where the review step kicks in — a plain description of what's about to happen, before it happens, and your explicit approval either one at a time or for a scoped set of operations you define upfront. This is the actual safety mechanism, and it only works if you read what it says rather than approving on reflex because the last several approvals went fine.
Say you ask Claude Code to fix a 404 link on a page. It reads the file (pre-approved), identifies the broken href, and proposes a specific edit — "change /old-path to /new-path in line 42." That proposal is what you review. You're not evaluating the whole codebase's safety; you're evaluating one small, specific, readable change. That's the model working as intended — small, reviewable units, not one big leap of trust.
Anything hard to undo (deleting files, force-pushing, dropping data) or anything that reaches outside the current project (a real external API call, a shared resource used by other projects) is worth a second, slower look — not because the review step fails to flag it, but because it's easy to skim past a routine-looking approval when you've built up a rhythm of quick yeses.
The free guide walks through it with a real first workflow — not just the abstract rules, an actual task you can run and watch the review step work.
Get the Free Guide →Only within whatever scope you've explicitly pre-approved — read-only exploration by default, with file edits and shell commands requiring your review unless you've set up a narrower auto-approved scope yourself.
Anything that's hard to undo or touches something outside the current project — deleting files, running a command that hits a real external service, or modifying something shared across multiple projects. The default review step catches most of this already; the discipline is not rushing past it for these specifically.
Yes, and it's a real tradeoff, not a free win — broader pre-approval means fewer interruptions but less chance to catch something before it happens. Most people narrow the pre-approved scope for unfamiliar or high-stakes projects and widen it for ones where they've already built trust in the pattern.
No — it's the mechanism that stops unapproved actions. It doesn't stop you from approving something you didn't actually read. Those are different problems, and only the first one is solved by the permission system itself.