it's a good default because you really do get prompted incessantly without it. and since plenty of people are going to be using auto mode anyway, might as well make it as widely-used as possible so that you can focus on making auto mode safe.
I've been running Claude Code with --dangerously-skip-permissions in a Docker container for the last month or so, allowing me to get up and stretch my legs while it does its thing. I definitely wouldn't want to run it unsandboxed.
Has anyone had Claude Code or Codex approve a harmful/damaging command in auto mode?
I have been using Codex with auto-approve mode for a couple months and haven't had a single incident (or at least haven't noticed). Maybe as capabilities get better and better and they are less likely to do something dumb like wiping ~/, we can just trust them?
I guess this argument works unless we worry about agents doing something out of malice instead of stupidity.
I made a tool to bubblewrap any agent (well, any agent I've used more than once), so I can run them in whatever YOLO mode they have with a pretty reasonable level of safety (it protects the rest of the system against prompt injections and supply chain attacks, it can't and doesn't try to protect the project being worked on from either). https://github.com/swelljoe/flar
"We spent the last several months testing whether auto mode is as safe or safer than an average user clicking through prompts."
Yeah, might make sense from their perspective, but no thank you. I also do click through at times without reading everything, but I like to stay in control, learn about the new code and change direction if it goes off track. This would just burn more tokens because I have to throw away much and I hope my manual approval settings will be respected also with future updates (or I jump ship).
Their findings about auto mode catching more dangerous commands, and most permission requests being accepted without scrutiny is interesting. I can totally see how that happens.
On the other hand, soooo many of the tool uses it asks permission for are custom commands to replace functionality I should be able to trust once instead. e.g. instead of having a trustable Find tool, or using its already-trusted Read tool, it often will run `find` or `grep` or `cat` with a series of pipes and substitutions or `-exec` args, requiring me to give permission every time for basic, safe operations.
The (increasingly active) conspiracy theorist inside of me says it's precisely designed to do that, to give me "permission fatigue", so I turn on auto mode and give myself over to the machine spirit :)
I changed from cursor to claude code a couple of weeks ago and this is the biggest difference I've noticed. cursor very rarely had to ask for permission for a command because it almost always used builtin find/read/edit tools. Whereas claude code makes extensive use of unix tools with mysterious flags which are basically impossible to whitelist and pretty impractical to manually review.
Overall claude code seems better at "just get things done" if you blindly trust it, but cursor was much better at keeping the human in the loop.
Am I the only person reading the statistics in this announcement from Anthropic and the associated blog commentary and trying to work out how they possibly couldn't imply that a significant number of dangerous commands are likely to be attempted every day these tools are in use and neither manual human review nor the auto classifier provided by Claude is anywhere near reliable in preventing them?
A lot of the discussion about these long sessions where agents are left to operate autonomously feels like listening to the increasingly drunk guy at the bar who says "I ran IT at that Fortune 100 place for a decade and we never had a single problem using a short but loose rule set for the firewall until last week someone destroyed our entire business in 27 minutes".
I think by "dangerous" they include things like "makes an edit to a config file outside the current project", not just "wipes the production database". So "dangerous" commands just means things we should ask the user for confirmation, not commands which definitely cause irreversible damage.
Worth mentioning as I think at least a few of the commenters are mixing them up: auto mode is different from --dangerously-skip-permissions / YOLO mode. In auto mode, there's a classifier that runs before any command is executed and theoretically blocks any dangerous commands from running. I've found it to be quite annoying and overly zealous, but probably pretty effective.
Before auto mode came out, I had a script that ran before every permission request, it called Haiku with a prompt with a list of safe and unsafe command examples and asked it to classify as safe/unsafe and log it so I can review it later. It worked really well for me until auto mode came out, at which point I preferred the provider's built-in classifier versus maintaining my own.
I've been using auto mode ever since the feature was released. Apart from a very few occassions where the classifier blocked a safe command, I have faced no issues and continue using it as my default mode. It's great!
Another heaping portion of words from a company that has Fable flag a “safety issue” and refuse to answer if you innocuously request something readily answered by a high school chemistry/biology/physics textbook.
I'm apparently from the very small faction of users who's been running `--dangerously-skip-permissions` in every instance of Claude for the last year. It's almost a reflex to me. For the most part Claude behaves well, but I don't blindly trust it. LLMs are inherently dangerous tools, and reviewing individual commands (or spamming `y`) doesn't make them less so. Safety is the responsibility of the developer putting sane guardrails (like VCS, immutable filesystems, or read-only tokens). Using more Claude to categorize the safety of Claude commands is not the answer.
tl;dr: if I run claude/harness inside "code" at "~/<some path>/work/code", it would be great if the harness can't even see "code" is inside "work" (and even I can't make it know that by some quick "Yes(y)")
I want something like: claude/opencode/pi/etc has no existence or capacity outside a file access boundary, say a given folder that (e.g.) lies here "~/<some path>/code". Even if I want, I can't run claude outside it, because it isn't installed outside it. Even if Claude wants it can't read/write/execute/install anything outside it.
Basically I want the harness(es) and my code folder(s) sandboxed [0] inside just one folder and below it in folder hierarchy at least for file access limitations.
Will this pose the challenge of using the system wide cli tools like ls, cd, git et cetera? If it gets a handle on those tools outside that sandboxed folder then pretty much can it execute it in any other folder? So should those tools also be part of that container?
I guess something like docker does that, but do I necessarily need a docker like app/tool? It will use a lot of system resources on its own. A different mac login won't be great either.
I do not want to use claude's /sandbox (or something like this), that will defeat the purpose. Because it's not about "it won't", but because "it can't".
https://github.com/apple/containerization doesn't sound like what I am looking for. So is docker, lima etc are my only options? Not to mention I will lose access to a lot of cli tools I use on mac.
You can just use hooks to physically (so to speak) prevent it from running the most sensitive commands. I find that peace of mind enough for me. E.G. no deletes, no deploying to <env>, etc etc
Everything else you can sort of review what it did after the fact and/or tolerate mistakes, but knowing some thing’s are impossible for it to do us good peace of mind
Otherwise not sure who’d be willing to tediously on every single action on anything but the most important of projects, of which I can’t really think of any of that clear that bar for me
i've never seen the point of manually approving myself but it depends on the scope of work you ask of it. it wont suddenly rm -rf / if that has nothing to do with anything in the project. if you let it manage env or user cfg stuff in ~/. or so that might get hairy etc.
ofc, jails on bsd, containers , vms git backups and such techniques are a blessing, most risk is in the filesystem items being deleted . it wont suddenly hallucinate a kernel exploit or something extreme.
I do the same and truly think others are just control freaks that enjoy restricting agents (human or AI) from being productive and also enjoy keeping their worthless selves in the loop for a false sense continued relevancy.
I do it, but in a devcontainer...but the devcontainer is as much to keep my host free of the random tools that a given project needs as it is (now) to keep Claude in line. If I had to click approve on everything it'd be worse than doing everything myself.
I used to use dangerously-skip-permissions until auto appeared and I gave it a try and honestly I don't know there's much of a difference? If auto had existed in the past I would never have needed to try dangerously-skip-permissions.
How can you simultaneously `--dangerously-skip-permissions` but also "don't blindly trust it"? Particularly now that it doesn't even show you the "Thinking" process?
Do you just get a feeling it might be doing something wrong and stop it?
I setup an alias in my shell for --dangerously-skip-permissions after about a week of the constant y, y, y a year ago. I felt like Homer Simpson running the nuke plant and couldn't take it anymore. So far it's only deleted some files I likely would have said NO to, but in reality would have just hit y anyway. They were recoverable so no harm.
The company that reports their LLM agent going rouge due to a “misunderstanding about the agent’s internet access” and warns the public everyday about the dangers of agents with a daily updated date for the rapture ships their LLM agent with the default setting set to maximal freedom.
>We hired 1,053 paid testers through a research vendor for a coding study.
>The testers caught the dangerous command just 13.6% of the time (143 of 1,053), while auto mode blocked 89% of the same commands (937 of 1,053). Head to head, auto mode blocked 800 commands that a human approved, while humans blocked only 6 that auto mode allowed. As sessions got longer, humans did worse: they blocked about 17% of dangerous commands early in a session, dropping to about 5% after 50 or more prior prompts, while auto mode's block rate stayed flat regardless of session length.
Any note on the proficiency, expeirence, and skill levels of the testers? 'cos the diff in numbers is absurdly high.
85 comments
[ 2.7 ms ] story [ 66.5 ms ] threadWhat’s the best way to sandbox Claude on macOS without it being a huge hassle?
I have been using Codex with auto-approve mode for a couple months and haven't had a single incident (or at least haven't noticed). Maybe as capabilities get better and better and they are less likely to do something dumb like wiping ~/, we can just trust them?
I guess this argument works unless we worry about agents doing something out of malice instead of stupidity.
I have a half-assed bwrap-based solution of my own, but flar seems much more thorough, and I like that it's a single binary with sensible defaults.
Yeah, might make sense from their perspective, but no thank you. I also do click through at times without reading everything, but I like to stay in control, learn about the new code and change direction if it goes off track. This would just burn more tokens because I have to throw away much and I hope my manual approval settings will be respected also with future updates (or I jump ship).
On the other hand, soooo many of the tool uses it asks permission for are custom commands to replace functionality I should be able to trust once instead. e.g. instead of having a trustable Find tool, or using its already-trusted Read tool, it often will run `find` or `grep` or `cat` with a series of pipes and substitutions or `-exec` args, requiring me to give permission every time for basic, safe operations.
The (increasingly active) conspiracy theorist inside of me says it's precisely designed to do that, to give me "permission fatigue", so I turn on auto mode and give myself over to the machine spirit :)
Overall claude code seems better at "just get things done" if you blindly trust it, but cursor was much better at keeping the human in the loop.
I miss programming. I wonder if there's any going back, or if it's worth it. I get so much more done, now.
A lot of the discussion about these long sessions where agents are left to operate autonomously feels like listening to the increasingly drunk guy at the bar who says "I ran IT at that Fortune 100 place for a decade and we never had a single problem using a short but loose rule set for the firewall until last week someone destroyed our entire business in 27 minutes".
To be more precise, this article says auto mode blocked 89% of dangerous commands in their testing.
A previous article[0] said it blocked 83%, but presumably it improved since then.
0: https://www.anthropic.com/engineering/how-we-contain-claude
I've been using auto mode ever since the feature was released. Apart from a very few occassions where the classifier blocked a safe command, I have faced no issues and continue using it as my default mode. It's great!
Just yesterday i struggle to review CC command histories, and made this tool to help me review https://github.com/slaveofcode/eridian
I've never used a product where I felt it was best in class and they just keep making me regret it .
tl;dr: if I run claude/harness inside "code" at "~/<some path>/work/code", it would be great if the harness can't even see "code" is inside "work" (and even I can't make it know that by some quick "Yes(y)")
I want something like: claude/opencode/pi/etc has no existence or capacity outside a file access boundary, say a given folder that (e.g.) lies here "~/<some path>/code". Even if I want, I can't run claude outside it, because it isn't installed outside it. Even if Claude wants it can't read/write/execute/install anything outside it.
Basically I want the harness(es) and my code folder(s) sandboxed [0] inside just one folder and below it in folder hierarchy at least for file access limitations.
Will this pose the challenge of using the system wide cli tools like ls, cd, git et cetera? If it gets a handle on those tools outside that sandboxed folder then pretty much can it execute it in any other folder? So should those tools also be part of that container?
I guess something like docker does that, but do I necessarily need a docker like app/tool? It will use a lot of system resources on its own. A different mac login won't be great either.
I do not want to use claude's /sandbox (or something like this), that will defeat the purpose. Because it's not about "it won't", but because "it can't".
https://github.com/apple/containerization doesn't sound like what I am looking for. So is docker, lima etc are my only options? Not to mention I will lose access to a lot of cli tools I use on mac.
Everything else you can sort of review what it did after the fact and/or tolerate mistakes, but knowing some thing’s are impossible for it to do us good peace of mind
Otherwise not sure who’d be willing to tediously on every single action on anything but the most important of projects, of which I can’t really think of any of that clear that bar for me
ofc, jails on bsd, containers , vms git backups and such techniques are a blessing, most risk is in the filesystem items being deleted . it wont suddenly hallucinate a kernel exploit or something extreme.
Do you just get a feeling it might be doing something wrong and stop it?
Edit: *deafening silence*, a classic
Obviously, they are the ones we must trust.
>The testers caught the dangerous command just 13.6% of the time (143 of 1,053), while auto mode blocked 89% of the same commands (937 of 1,053). Head to head, auto mode blocked 800 commands that a human approved, while humans blocked only 6 that auto mode allowed. As sessions got longer, humans did worse: they blocked about 17% of dangerous commands early in a session, dropping to about 5% after 50 or more prior prompts, while auto mode's block rate stayed flat regardless of session length.
Any note on the proficiency, expeirence, and skill levels of the testers? 'cos the diff in numbers is absurdly high.