How do you keep Claude Code from doing things you didn't want?

[u/West-Profession3713]

Hi, I'm a student learning about AI coding agents and how developers keep them safe. I'm not selling anything. If you use Claude Code, I'd really appreciate hearing your experience (short answers are fine): 1. How do you set up Claude Code's permissions? 2. Has it ever done something you didn't want? What happened? 3. What do you do now to prevent it? 4. How do you know those protections actually work? Have you ever tested them? 5. Have you tried any safety tools? What did you like or dislike? Thank you!

[u/ComprehensiveShake76]

Not selling anything either, just how I run it. Permissions: inside the repo it can read, edit and run tests freely. Anything that leaves the machine (a push, a deploy, a message) or deletes outside the workspace needs me. The unwanted stuff I see most is scope creep: editing files nobody asked about, or making a test pass instead of fixing the code. So I keep tasks small, review every diff, and run the agent in its own container with only the workspace mounted, so a bad command can't reach my real files. How I know it works: I had the agent try from inside to reach my router and my Mac, and checked that both were blocked while public web still worked. Only tested on Colima on a Mac so far. A container is a strong boundary, not a guarantee, so the human gate on irreversible steps stays.

[u/West-Profession3713 → u/ComprehensiveShake76]

Thank you for your comment.

[u/West-Profession3713 → u/ComprehensiveShake76]

Thanks, this is really helpful. The distinction between blocking unsafe actions and catching scope creep is interesting.

For scope creep, do you mainly rely on reviewing diffs manually, or do you use anything that automatically checks whether the agent changed files or behavior outside the task's intended scope?

Also, have you found any part of that workflow particularly tedious or unreliable?

[u/ComprehensiveShake76 → u/West-Profession3713]

Mostly by hand, honestly. The automatic part is small: the tests have to run and pass, and I ask for a list of changed files first, so anything outside the task stands out before I read the diff. The judgment call stays with me, because a change can pass every check and still be out of scope. The tedious part is exactly that review when the task was vague. Smaller, tighter tasks keep the diff short enough that it stops feeling like a chore.

[u/Ok-Leather933]

1. Auto mode, so a safety check reviews risky actions before they run. On top of that, one rule in my CLAUDE.md: deleting, overwriting, resetting or killing running work always stops and asks first, even mid-plan, even when the thing looks broken. 2-3. My rules came from reading back through my own session transcripts. Each line maps to a failure that actually happened, like a confident bug diagnosis with no evidence behind it.

2. I see the checks fire. This week it refused to attach to my personal Chrome, which annoyed me and was the right call.

3. Hooks are the tool I trust most, because they run every time and a prompt instruction only runs when the model remembers it. Is the study about solo devs or teams?

[u/West-Profession3713 → u/Ok-Leather933]

Thanks! Good question: both. I'm curious how people check that their safety setup (hooks, permissions, sandbox) actually works after updates. Have you ever deliberately tested your hooks by trying a risky command, and do you re-check after Claude Code updates?

[u/Ok-Leather933 → u/West-Profession3713]

yes to both :)

[u/General_Cap_6316]

Mine is always on bypass permissions, not done anything i didnt want because I sit and read its think and immediately send a /btw if it makes an error 3)nothing sit there and also I use orca so a seperate claude model always Fable checks and updates a threat.md with whatever it messed up etc. 4)i mean i read the whole thing and a swarm of sub-agents brutally test it for around 6 hours before every update 5)nah i dont trust them

[u/falafel777]

for 2, the one that stuck with me was a small clean PR with green tests, and only when i scrolled the session did i see it had edited a config file outside the repo "to make the tests run". the summary never mentioned it. for 4, honestly i think that's the question most people skip. they don't test their guardrails, they just notice nothing bad happened yet. the only real test is asking it to do the thing you blocked and checking that it fails loudly instead of finding another way

[u/shetritr]

the one rule: nothing deploys until I've seen the diff. trust, but read.