i've low-key been running claude in dangerously skip permissions mode for at least like 4 months now and have yet to be bitten by a truly destructive action. YMMV but i think as long as you're guiding/prompting correctly, and don't just allow write access to your prod account DBs willy nilly, it's mostly fine. just keep an eye on it :shrug:
Running Claude Code dangerously (safely)
101–110 of 265 posts
Re: Running Claude Code dangerously (safely)
#102Keeping in mind with Vagrant: if you are using a synced_folder in your host as a source folder in the VM, those files in the synced_folder will be modified on the host.
If the folder is versioned and commited regularly there is no problem. It also allows you to open the files in your IDE, do some other tasks or fixes for claude. It prevents claude from accessing any other folder, which is the idea of the post.
Until Claude nukes .git, assuming you're using git as the version/commit store. Solution use easy, just push to a remote on a reasonable cadence (that you can run reflog on, so a force push won't eat your data either). Git isn't backup though, it's a VCS, and those are two different things, even if they are somewhat alike.
Re: Running Claude Code dangerously (safely)
#103Since everyone tends to present their own solution, I bid you mine:
sandbox-run npx @anthropic-ai/claude-code
Re: Running Claude Code dangerously (safely)
#104i've low-key been running claude in dangerously skip permissions mode for at least like 4 months now and have yet to be bitten by a truly destructive action. YMMV but i think as long as you're guiding/prompting correctly, and don't just allow write access to your prod account DBs willy nilly, it's mostly fine. just keep an eye on it :shrug:
Also something to note, this mode simply adds a new mode alongside accept edits, plan, nothing, dangerously skip permissions. You can choose when to use it or not, which is not something I initially realized.
Re: Running Claude Code dangerously (safely)
#105How about running Claude as a different user with very limited permissions?
I run it with sudo enabled - true story just give it its own machine and let it check out any code I PXE boot it from a known image when I feel the need
Same solution here - keep a base diskless image on the server, copy it to the diskless area, pxeboot the machine. Works for Windows too (iscsi).
Could do the same thing on EC2 of course.
Re: Running Claude Code dangerously (safely)
#106I'm pursuing a different approach: instead of isolating where Claude runs, intercept what it wants to do. Shannot[0] captures intent before execution. Scripts run in a PyPy sandbox that intercepts all system calls - commands and file writes get logged but don't happen. You review in a TUI, approve what's safe, then it actually executes. The trade-off vs VMs: VMs let Claude do anything in isolation, Shannot lets Claud…
I'm struggling to see how this resolves the problem the author has. I still think there's value in this approach, but it feels to be in the same thrust as the built in controls that already exist in claude code. The problem with this approach (unless I'm misunderstanding - entirely possible!) is that it still blocks the agent on the first need for approval. What I think most folks actually want (or at least what I wa…
You're right that blocking on every operation would defeat the purpose! Shannot is able to auto-approve safe operations for this reason (e.g. read-only, immutable)
So the agent can freely explore, check logs, list files, inspect service status. It only blocks when it wants to change something (install a package, write a config, restart a service).
Also worth noting: Shannot operates on entire scripts, not individual commands. The agent writes a complete program, the sandbox captures everything it wants to do during a dry run, then you review the whole batch at once. Claude Code's built-in controls interrupt at each command whereas Shannot interrupts once per script with a full picture of intent.
That said, you're pointing at a real limitation: if the fix genuinely requires a write to test a hypothesis, you're back to blocking. The agent can't speculatively install a package, observe it didn't help, and roll back autonomously.
For that use case, the OP's VM approach is probably better. Shannot is more suited to cases where you want changes applied to the real system but reviewed first.
Definitely food for thought though. A combined approach might be the right answer. VM/scratch space where the agent can freely test hypotheses, then human-in-the-loop to apply those conclusions to production systems.
Re: Running Claude Code dangerously (safely)
#107"At some point I realized that rather than do something else until it finishes, I would constantly check on it to see if it was asking for yet another permission, which felt like it was missing the point of having an agent do stuff"
Why don't Claude Code & other AI agents offer an option to make a sound or trigger a system notification whenever they prompt for approval? I've looked into setting this up, and it seems like I'd have to wire up a script that scrapes terminal output for an approval request. Codex has had a feature request open for a while: https://github.com/openai/codex/issues/3052
Re: Running Claude Code dangerously (safely)
#108Since everyone tends to present their own solution, I bid you mine: sandbox-run npx @anthropic-ai/claude-code This runs npx (...) transparently inside a Bubblewrap sandbox, exposing only the $PWD. Contrary to many other solutions, it is a few lines of pure POSIX shell. https://github.com/sandbox-utils/sandbox-run
I like the bubblewrap approach, it just happens to be Linux-only unfortunately. And once privileges are dropped for a process it doesn't appear to be possible to reinstate them.
Re: Running Claude Code dangerously (safely)
#109Earlier quoted context omitted.
One recent example. For some reason, recently Claude prefer to write scripts in root /tmp folder. I don't like this behavior at all. It's nothing destructive, but it should be out of scope by default. I notice they keep adding more safeguards which is great, eg asking for permissions, but it seems to be case by case.
If you're not using .claude/instructions.md yet, I highly recommend it, for moments like this one you can tell it where to shove scripts. Trickery with the instructions file is Claude only reads it during a new prompt, so any time you update it, or Claude "forgets" instructions, ask it to re-read it, usually does the trick for me.
Claude, I noticed you rm -rf my entire system. Your .instructions.md file specifically prohibits this. Please re-read your .instructions.md file and comply with it for all further work
Re: Running Claude Code dangerously (safely)
#110`useradd claude`
This is the solution I chose for sandvault [0], which works well on my Mac since agents can run OSX-specific tools.
It just got added to Homebrew:
brew install sandvault