Permissions & Safety Basics

Tier 0 · Total Beginner 9 min read

You’ve been approving prompts since your first edit. This page explains what those prompts are, the choices they offer, and the one mode you should be slow to turn on. An agent that can run commands and change files is powerful — the permission system is what keeps that power pointed where you want it.

Note

Prereq: Your First Session.

---

Why permissions exist at all

Claude Code can do real things: write files, delete files, run terminal commands, install packages. Most of those actions are harmless. A few are not — deleting a folder, overwriting a config, running a command that touches your whole system. The agent can’t always tell which is which from your one-line request, and it occasionally misreads what you meant.

The permission prompt is the seatbelt. Before the agent takes an action it can’t easily undo, it stops and asks you. That pause is your chance to catch a mistake while it’s still just a proposal.

What a permission prompt offers

When the agent wants to do something gated, you’ll see a prompt describing the action and giving you choices. The exact wording varies, but the shape is consistent:

• Approve once — let this one action happen. The agent asks again next time.
• Approve and stop asking for this kind of action (for the rest of the session) — useful when you’re doing many similar, safe operations and don’t want to click for each.
• Deny / reject — don’t do it. The agent stops and you can tell it what to do instead.

1. Read what it’s about to do. The prompt names the action — which file, which command. Don’t skim.

2. Decide based on reversibility. Reading a file? Trivially safe. Writing a new file? Low risk. Deleting something or running a command that changes system state? Slow down and look hard.

3. Approve, scope, or deny. When in doubt, approve once rather than “stop asking” — you keep the seatbelt on for the next one.

Tip

There’s a keyboard shortcut for cycling permission modes inside a session — press Shift+Tab to move between asking-every-time and more permissive modes. Knowing the shortcut exists matters less than knowing which mode you’re in. Glance at the mode before you let it rip on a sensitive task.

”Accept all” and bypass mode — handle with care

To save clicks, Claude Code lets you loosen the prompts. The mild version is an “accept edits” / “accept all” mode for a session, where it stops asking before each file change. That’s reasonable once you trust what it’s doing in a known-safe folder.

The aggressive version is a bypass mode that skips permission prompts almost entirely. There’s a real use for it — fully unattended automation, where there’s no human present to click “approve.” But it removes the seatbelt. In bypass mode, a misread instruction or a runaway loop can delete or overwrite things with no checkpoint.

Caution

Don’t run bypass mode while you’re learning, and never in a folder you’d hate to lose. If you do use it for automation later, scope the working directory tightly, work in a folder under version control (so any change is reversible with git), and assume the agent will eventually do something you didn’t intend — design so that when it does, the blast radius is small.

The rule worth keeping: confirm before anything destructive

This site’s larger system encodes a single hard rule that every beginner should adopt from day one:

Confirm before running destructive operations — deleting files (rm -rf), force-pushing git, dropping a database table, and the like. Never let those happen unattended without a checkpoint.

The reasoning is simple: reversible actions are cheap to get wrong (you just redo them), but destructive ones aren’t (the data is gone). So the cost of a confirmation prompt on a destructive action is a few seconds, and the cost of not having one can be your whole afternoon — or your data. Keep the seatbelt on for the actions that bite.

Two safety nets you get for free

1. Working-directory scoping. As covered in the working directory page, the agent operates inside the folder you launched it from. Launch it in the right project and a lot of “oops” is impossible by construction.
2. Version control. If your project is a git repository, every change is recoverable — you can see exactly what the agent changed and undo it. Working inside git turns “the agent broke something” from a disaster into a one-command rollback. (Tier 1 covers git discipline for agents in full.)

The mindset

Permissions aren’t bureaucracy — they’re the line between “an assistant that proposes” and “a process that acts on its own.” For everything you do by hand, keep the prompts on and read them. For automation, earn the right to loosen them: tight folder, version control, small blast radius, and a way to see what happened after the fact.

---

Next: Reading the Output — how to interpret a session’s tool calls and results, and how to tell when the agent is genuinely stuck.

Enjoyed this? Get weekly agent architecture insights.

Subscribe and get a free Agent Architecture Cheatsheet.

Subscribe