# Permissions, and being honest about the risk

Course: Claude Code from Zero — https://zero2vibecode.com/learn/claude-code
Canonical URL: https://zero2vibecode.com/learn/claude-code/3-4-permissions-safety

An agent with file access and a shell can do real damage. The controls are simple and worth understanding on the day you install it, not the day something goes wrong.

Everything useful about this tool comes from one fact: it can act. Everything dangerous comes from the same fact. Let us be specific rather than vague.

## What it can actually do wrong

**Delete or overwrite the wrong thing.** A command with a wrong path is one character away from a correct one, and it does not hesitate the way you would.

**Expose a secret.** Reading a key is harmless. Pasting it into a file, a log, or a commit is not, and any of those can happen inside one helpful-looking change.

**Commit and publish.** If it can run `git`, it can commit. If it can push, what is on your machine can leave it.

**Follow instructions that were not yours.** Text it reads — a fetched web page, an issue description, a file in a dependency — can contain something shaped like an instruction. This is prompt injection, and the defence is that the resulting action is still visible to you, if you are looking.

**The honest sentence.** 
An agent with file access and shell access is, for the duration of your session, a program running with your own permissions — it can read, change or run anything your user account can — executing commands you did not write. Everything below is about making that a controlled situation instead of a hopeful one.

## The permission prompt is the review

By default, Claude Code asks before it does things that matter. The prompt tells you the action; your answer is yes, yes-and-stop-asking-for-this, or no.

That prompt is not an annoyance to click through. It is the single moment where you can still say no. Read the command. If you do not understand it, ask what it does before approving it — asking is free.

**Yes-and-stop-asking** is genuinely useful for the boring repeats: running your test suite forty times in an afternoon. It is a bad answer for anything that deletes, publishes, or reaches outside the project.

## Rules that persist

Settings files let you decide once instead of every time. They live in your project's `.claude` folder — one committed for the team, one local and untracked for your own overrides — and there is a personal one in your home directory that applies everywhere.

The two useful shapes:

- **Allow** the safe and frequent, so you are not interrupted forty times a day. Your test command is the obvious candidate.
- **Deny** the genuinely dangerous, so it cannot happen even if you are tired and clicking fast. Paths holding secrets, commands that publish, anything touching production.

Deny rules matter more than allow rules. An allow rule saves you time; a deny rule saves you an incident.

**Instructions are not enforcement.** 
"Never touch `.env`" in CLAUDE.md makes the right behaviour much more likely. A deny rule makes the wrong behaviour impossible. When it matters, use the second one. `/permissions` in a session shows you what is currently in force.

## Skipping permissions

There is a flag that turns off the prompts entirely. It exists because there are legitimate uses: an isolated container, a throwaway virtual machine, an automated run where nobody is watching a terminal.

It is not a productivity setting for your laptop. Turning it off is removing the review step from a system whose main failure mode is confident, well-formatted wrongness. Claude Code also has sandboxing options for running commands with limited filesystem and network access — better tools for the same goal, and worth reading about before you reach for the blunt one.

## The three things that actually protect you

1. **Git.** A committed project turns almost every mistake into `git restore`. This is the big one.
2. **Scoped credentials.** Whatever key the agent could reach, assume it could be used. Read-only where read-only will do. Never a production key in a development folder.
3. **Reading what it does.** Not skimming. Reading. This is the control that catches the things the other two cannot.

**A reasonable starting posture.** 
Prompts on. Project in Git, committed. No production credentials anywhere near the folder. Allow your test command once you are tired of approving it. Add deny rules the first time something makes you nervous.

<Faq>
  
  
</Faq>

## Try it yourself

A permission prompt, and the three answers you can give it.