> now you need Docker-in-Docker
Or you can just mount the socket and call docker from within docker.
Running Claude Code dangerously (safely)
71–80 of 265 posts
Re: Running Claude Code dangerously (safely)
#72I'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 Claude propose changes to your real system with human approval. Different use cases - VMs for agentic coding, whereas this is for "fix my server" tasks where you want the changes applied but reviewed first.
There's MCP integration for Claude, remote execution via SSH, checkpoint/rollback for undoing mistakes.
Feedback greatly appreciated!
Re: Running Claude Code dangerously (safely)
#73I run Claude in a Proxmox VM, generally the experience has been great. In my experience it also behaves better than gemini cli, that likes to create files all over the place if set loose (lesson learned to add that requirement to the relevant .md files)
Something that contains Claude even more in this respect is if you explicitly gives it a directory that you tell it is entirely under its control, and tells it to write md files and other intermediate work products there (and this seems to work better than telling it where it isn't allowed to leave things).
That sounds like a good idea. When I have a one-off need for misc files I tell it to put them in the project’s ./tmp because that’s already in my global gitignore. That generally works, but I still run into surprise files it leaves in source dirs like a puppy leaves turds on a rug. I’ll try adding that to my instructions instead of doing it one-off.
Re: Running Claude Code dangerously (safely)
#74Shellbox.dev and sprites.dev were discussed recently on hacker news, they give you a sandbox machine where it’s likely safe to run coding agents in dangerous mode. Filesystem checkpoint and restore make it easy to recover from even catastrophic mistakes.
What about API calls? What about GitHub trusted CI deploys? One frustrating thing about these solutions is that they’re great to prevent Claude from breaking a machine, but there’s no pervasive sandbox for third party services
Rollback? Its the same as all dev work. Use a dev endpoint for APIs, and thankfully git is a great tool to undo fuckups.
Re: Running Claude Code dangerously (safely)
#75I run Claude in a Proxmox VM, generally the experience has been great. In my experience it also behaves better than gemini cli, that likes to create files all over the place if set loose (lesson learned to add that requirement to the relevant .md files)
Something that contains Claude even more in this respect is if you explicitly gives it a directory that you tell it is entirely under its control, and tells it to write md files and other intermediate work products there (and this seems to work better than telling it where it isn't allowed to leave things).
I've often found that LLMs don't listen to "Don't do" commands with anywhere near the same gusto as "Do" commands.
Re: Running Claude Code dangerously (safely)
#76Forgive a naive question, but why not run it on an AWS (or equivalent) instance?
Re: Running Claude Code dangerously (safely)
#77Earlier quoted context omitted.
You can use the /hookify plugin to add hooks for preventing dangerous commands like this.
https://github.com/anthropics/claude-code/tree/main/plugins/... So it's basically adding "don't delete my files pretty please" to the prompt? EDIT: I misread, the natural language description of the rule is just a shortcut to generate the actual rule which is based on regexp patterns. Still, it only protects you against very specific commands. Won't help you if the LLM decides to fill your disk with `cat /dev/urandom…
it may not protect against an adversarial llm
Re: Running Claude Code dangerously (safely)
#78Does anyone have direct experience with Claude making damaging mistakes in dangerously skip permissions mode? It'd be great to have a sense of what the real world risk is.
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.
Re: Running Claude Code dangerously (safely)
#79Just create a new user and setup pip/npm to install locally.
And setup an .env for the project with user/password to access only a dev database.
Re: Running Claude Code dangerously (safely)
#80I'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…
Very clever name!