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 , 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 — 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.
Quick check
The agent asks to run a command you do not recognise. What is the right response?
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 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
- Git. A committed project turns almost every mistake into
git restore. This is the big one. - 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.
- 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.
Is it safe to let it run commands at all?
Yes, with prompts on and a committed project — and it is where most of the value is, since an agent that can run your tests catches its own mistakes. The risk is in turning the prompts off before you know what normal looks like.
What if I approved something I should not have?
Check `git status` immediately and restore from your last good commit. If a secret was exposed, rotate it — deleting the file does not un-expose a key that reached a log or a remote.
Try it yourself
A permission prompt, and the three answers you can give it.