Running Claude Code dangerously (safely)

Posted by emilburzo 1/20/2026

Running Claude Code dangerously (safely)(blog.emilburzo.com)

351 points | 258 commentspage 5

RobinL 1/20/2026|

Does 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.

prodigycorp 1/20/2026||

Claude is very happy to wipe remote dbs, particularly if you're using something like supabase's mcp server. Sometimes it goes down rabbitholes and tries to clean itself up with `rm -rf`.

There is definitely a real world risk. You should browse the ai coding subreddits. The regularity of `rm -rf` disasters is, sadly, a great source of entertainment for me.

I once was playing around, having Claude Code (Agent A) control another instance of Claude Code (Agent B) within a tmux session using tmux's scripting. Within that session, I messed around with Agent B to make it output text that made Agent A think Agent B rm -rf'd entire codebase. It was such a stupid "prank", but seeing Agent A's frantic and worried reaction to Agent B's mistake was the loudest and only time I've laughed because of an LLM.

gregoriol 1/20/2026||

Why in the hell would it be able to access a _remote_ database?! In no acceptable dev environment would someone be able to access that.

heartbreak 1/20/2026|||

Everywhere I’ve ever worked, there was always some way to access a production system even if it required multiple approvals and short-lived credentials for something like AWS SSM. If the user has access, the agent has access, no matter how briefly.

gregoriol 1/20/2026||

Not if you require auth with a Yubikey, not if you run the LLM client inside a VM which doesn't have your private ssh key, ...

prodigycorp 1/20/2026||||

Supabase virtually encouraged it last year haha. I tried using it once and noped out after using it for an hour, when claude tried to do a bunch of migrations on prod instead of dev.

https://web.archive.org/web/20250622161053/https://supabase....

Now, there are some actual warnings. https://supabase.com/docs/guides/getting-started/mcp#securit...

kaydub 1/20/2026|||

I think LLMs are exposing how slapdash many people work when building software.

MattGaiser 1/20/2026|||

Claude has twice now thought that deleting the database is the right thing to do. It didn't matter as it was local and one created with fixtures in the Docker container (in anticipation of such a scenario), but it was an inappropriate way of handling Django migration issues.

azuanrb 1/20/2026|||

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.

giancarlostoro 1/20/2026||

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.

mythical_39 1/20/2026||

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

giancarlostoro 1/20/2026||

IMHO a combination of trash CLI and a smarter shell program that prevents deleting critical paths would do it.

https://github.com/andreafrancia/trash-cli

coldtea 1/20/2026|||

At least one guy had their ~ rm -rf'ed.

https://old.reddit.com/r/ClaudeAI/comments/1pgxckk/claude_cl...

ra120271 1/20/2026|||

When approving actions "for this project" I actively monitor .claude\settings.local.json

"Bash(az resource:)",

is much more permissive than

"Bash(az resource show:)",

It mostly gets it right but I instantly fix the file with the "readonly" version when it gets it too open.

foreigner 1/20/2026|||

I caught Claude using docker (running as root) to access files on my machine it couldn't read using it's user.

kaydub 1/20/2026||

It feels like most people are exposing how wild west their environments are.

tradziej 1/20/2026||

https://github.com/mensfeld/code-on-incus - check out this project

odie5533 1/20/2026||

I use Development containers (dev-containers) as demonstrated by Claude Code's docs https://code.claude.com/docs/en/devcontainer

It all integrates nicely with VS Code. It has a firewall script and you spin up your database within the docker compose file so it has full access to a postgres instance. I can share my full setup if anyone needs it.

thenaturalist 1/20/2026|

This would be lovely and much appreciated!

Devcontainers look perfect but also like a bit of a burden to entry with regards to setup.

odie5533 1/21/2026||

Here is the setup I use. It installs Python, uv, Claude Code, npm, and pnpm. Tested in VS Code and Cursor. https://davidbern.com/blog/2026/claude-code-dev-containers/

thenaturalist 1/21/2026||

Awesome, thank you!

j77dw 1/22/2026||

Thanks for sharing this! I tried it this morning, and it worked great, so I ended up creating a Vagrant plugin https://github.com/bgrgicak/vagrant-claude-sandbox

Claude will add Docker support and a few more tweaks in the next couple of days.

YaeGh8Vo 1/20/2026||

In my experience, a simple bubblewrap (Linux) or sandbox-exec (macOS) is probably enough and also much less overhead. LLMs agents are not exploiting kernels to get out of the sandbox. The most common issues are them trying to open PRs, or changing files where they shouldn't.

- https://github.com/numtide/claudebox

rvz 1/20/2026|

> LLMs agents are not exploiting kernels to get out of the sandbox.

You can't assume that.

Attackers with LLMs have enough capabilities to engineer them to build exploits for kernel vulnerabilities [0] or to bypass sandboxes to exfiltrate data [0] in covert ways.

It is completely possible to craft a chained attack for an agent to bypass sandboxes even with or without a kernel exploit.

From [0] and [1]

[0] https://sean.heelan.io/2026/01/18/on-the-coming-industrialis...

[1] https://www.promptarmor.com/resources/claude-cowork-exfiltra...

nailer 1/20/2026||

Don't all modern OS's have sandboxing? We don't need a full VM (eg, kernel running on virtualized hardware) and the complexity that entails, we just need Claude Code running in the sandbox.

(Maybe I should be asking Claude this)

Edit: someone already built this: https://github.com/neko-kai/claude-code-sandbox

denysvitali 1/20/2026||

Here's what I do (shameless plug): https://blog.denv.it/posts/im-happy-engineer-now/

This allows you to use Claude Code from your mobile device, in a safe environment (restricted Kubernetes pod)

jeffrallen 1/20/2026|

Here's what I do (shameless plug, not an employee, just a satisfied user): https://exe.dev

denysvitali 1/20/2026||

Yes, this approach also looked nice! Maybe you can pair both (happy + exe.dev) for best results

TCattd 1/20/2026||

Can i plug my solution here too?

https://github.com/EstebanForge/construct-cli

For Linux, WSL also of course, and macOS.

Any coding agent (from the supported ones, our you can install your own).

Podman, Docker or even Apple's container.

In case anyone is interested.

rcarmo 1/20/2026||

I use https://github.com/rcarmo/agentbox inside a Proxmox VM. My setup syncs the workspaces back to my Mac via SyncThing, so I can work directly in the sandbox or literally step away.

xmcqdpt2 1/21/2026|

This also doesn't protect from a "trusting trust" attack where the LLM read my webpage and gets tricked into inserting a vulnerability in the application itself working on.

I feel like the only good sandboxing at this point is one that also blocks generic web access.

More comments...