My experience is that I can't even review command that Claude wants to run because it is truncated when displayed in the terminal. How can I make a educated choice then?
This now looks like a deliberate UX choice to blame humans who don't review options, and then just remove the choice. A dark pattern to push the product.
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.
I'm also in yolo mode, this is the only mode that makes sense for me, if I need to babysit I might as well do it myself.
I run it in a VM so it can install any software needed, yes, there is a risk of escaping, but I'm not giving it impossible tasks so there is no need for it to workaround the jail.
I'm assuming this happens to the people vibe coding and running 30+ agents in parallel that are "coordinating" each other. I've never seen Claude do or even suggest anything remotely dangerous when I'm just giving it incremental tasks and reviewing the output.
Whatever level of safety you are at, it's always easy to advocate for more. It's always a trade-off and in the end a matter of preference and risk-tolerance.
VMs and containers are primarily useful to reduce maintenance burden anyway. I.e. if it fails or you're otherwise done with it, you can torch the container instead of having to clean up your host system from zillion no longer relevant packages and configs.
I'm using a container. The risk isn't exactly "agent leverages 0-day against you to steal all your data" but more "agent mistakenly though $HOME was theirs and deleted it" so as long as you "copy data in > copy data out" without bind-mounting or automatically sync files, container works just fine for "isolating" them.
I've tried both incus and firecracker. Both seem to work well after initial script setup. I've got the impression that firecracker should be a fairly safe option for such use cases.
I manually approve everything (aside from the "allow commands like this" option). Not because I'm worried it's about to do something harmful but because I want to stop it from wasting tokens doing something stupid like implementing a feature I never asked ask for. I'm not even reading the commands, just checking it's going in vaguely the right direction.
I think my ideal setup would not involve approving commands, but approving summaries of proposed actions (whether they involve code exec or file edits). Kinda like plan mode but perpetual. Like most things, trying to solve it via CLAUDE.md is an exercise in futility.
I think all of Anthropic's own staff use --dangerously else they'd work on the usability of the massively imperfect 1-approve-once and 2-approve-forever multi-choice and outcome.
I too skip all permissions, but I run the harnesses inside an isolated virtual machine. I took care to firejail Claude Code on my host since day one, and coding my own QEMU VM orchestration solution was among the first things I used it for.
Alarm fatigue will quickly destroy any and all "meticulously approve every little command the AI wants to run" workflows. Give it a virtual machine and let it cook. If it blows up the virtual machine while it works, it doesn't matter.
I haven't (and won't) gone that far, but what's been working for me is denying all arbitrary code execution, grep, glob etc, and then allowing the JetBrains MCP. At least that way it's essentially locked down to the IDE project.
Then you can treat most asks as a signal something has gone wrong. For the most part it seems to work well within that box.
My .bashrc has `alias claude='claude --dangerously-skip-permissions'`
Been using it like that everyday for about a year now and nothing bad has happened. I got backups and if it would fuck things up, it can probably fix it again as well.
This is the same reasoning for not wearing seat belts or a helmet on a motorcycle. Nothing bad has happened yet so obviously there is no need for any protection.
I've been raw dogging Claude Code for the better part of last year as well, but I'm under no illusion that it's safe to do so, I just cannot approve seven trillion approval prompts and stay sane. I've since. switched to auto mode, however.
I use dontAsk mode[0] with read access to the entire file system, write access to files from the working directory[1], some git commands (git commit yes, git push no), and a script wrapping Deno with the same read/write permissions (safer substitute for `python -c`).
These are usually enough for most of my coding tasks. In my experience, Claude has been good enough that it can write code and fix bugs without needing anything else. It's far better than ever needing to approve permission requests.
This is the only kind of agent security that makes sense to me. Constrain it like you would any other subprocess. Unprivileged OS users, SELinux, firewalls, VMs... Unikernels? eBPF?
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.
I do the same. I also use crush/deepseek a lot. I patched crush to remove all safetyguards and enable yolo mode by default. I use it on a daily basis including devops. For example to configure netapp storage systems and had not a single incident. Of course I also have backups of my systems and have everything under revision control. Depending on the task I let it run on a throw away VM, production system, lab system. Depending on the task I give it access to throwaway credentials (that I rotate afterwards) or my ssh agent socket.
My issue is that the auto mode guard rail model, is sometimes overwhelmed and really slow, so I also mostly just default to --dangerously-skip-permissions.
I wish the command would be easier to write like --dsp
For personal stuff I have a separate physical machine on the network that Claude runs on in yolo mode and the worst it can do over there is wipe the machine. It doesn't have privileged access to anything else unless it starts trying to hack my network, which I suppose is theoretically possible with prompt injection attacks.
For work stuff in the work environment I don't risk it.
> I wish the command would be easier to write like --dsp
It amazes me they didn't make the short version --yolo ... but I would imagine the merit of the long name is that you can't claim you weren't warned!
Yeah, if you don't care if your ssh keys or data are potentially posted all over the internet, more power to you...
Not to mention cases like some comment here:
"I've caught Fable discovering the ip to a production server in documentation and attempting to connect there on its own to run commands without explicitly being prompted to. It didn't work because I was watching it live and and also the key was password protected, but yeah, I do see some danger."
I don't see how. An LLM just generates a stream of output and they became very useful doing no more than that.
What is dangerous is then interpreting that output as instructions to some other part of a system that has the ability to do damage if misused.
and reviewing individual commands (or spamming `y`) doesn't make them less so.
Surely if you review each instruction in the output and do not allow the other part of the system to act on one if it would be harmful then this arrangement is very much less dangerous?
I've caught Fable discovering the ip to a production server in documentation and attempting to connect there on its own to run commands without explicitly being prompted to. It didn't work because I was watching it live and and also the key was password protected, but yeah, I do see some danger.
Not only fable. Opus does this too. Which is exactly why I want to review. Like recently for some task it was convinced in a site dump images are not there and convinced itself db and files were skewed. But it didn’t check the actual site … if I hadn’t stopped it, it would have fine on and on or wasted tokens on some elaborate ‘fix’.
Besides the debate about whether this is "safer" than manual human review, I have a slightly different problem.
Very often, when I'm running Claude in manual review mode, it will attempt to do things which are not "dangerous" but are misaligned with what I want it to do. Maybe I'm fighting the model here but for example, when orchestrating other agents to do work, Claude really badly wants to be overly prescriptive about how the work gets done, telling them exactly which files to edit, exactly what not to do, etc. instead of trusting the guardrails, review agents, or humans in the process to catch code-level mistakes. And no, telling it not to do this does not stick. Manual review is the last line of defense I have here.
I have stuff I don't want blacklisted, only allow it to use tools with limited ability to boss around agents, and various hooks to try and catch behavior that the permissioning system can't. If I use Auto mode though, I lose this control. The classifier will gleefully approve these types of commands because guess what, it's also Claude.
> Maybe I'm fighting the model here
> And no, telling it not to do this does not stick.
You're fighting the model, don't argue with city hall. Set the standards and let it figure out how to execute, stop getting bogged down in the minutia. I try, as much as I can, to treat the session as a black box - only the inputs and outputs matter, internal prompting of subagents is way out of scope.
You can't change it via prompt, and you can't control the guardrails, so something else has to give - either your perspective or the system you're managing. If you really believe that the internal prompting is bad, turn off subagents and workflows and only let it execute in thread.
But if you're going to do that, you'd better benchmark it against not doing that, because historically fighting the harness and model globally makes everything worse. I would bet you that the subagent prompting is excellent, and anything you do to change it will make it worse, but I wouldn't make it a large bet.
If I ask a model to do a change involving editing a file, and it starts investigating internals of my build system, then sure it might not be counterproductive or break the task, and might have taken only extra 30 seconds; but for all I know, my quick rejection of a shell invocation (with a simple "irrelevant to the task" comment) might have just saved me half of today's Opus tokens, which already makes it worth it.
"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).
The default is set for the marginal new user, which at this point is probably not someone like you (who benefits a lot from manual mode) -- it's someone who's more "code-naive" and might get anxious about approving random bash script commands they don't recognize. Safely getting the user from prompt --> first vibe-coded app is the "user journey" now, and since auto mode seems pretty good at not letting Claude rm -rf'ing the home directory, this is 100% the right business move. For people who know what they're doing (like you), manual mode is just a shift-tab away
I don't think the marginal new user is anxious about approving messages - I think they're quickly annoyed by permissions prompt they don't understand and quickly get in the habit of approving everything or figuring out how to set bypass permissions on
I recall hearing similar sentiments from linux sysadmins regarding cloud infrastructure. In many respects they were and continue to be correct. In other respects, the world doesn’t care about the loss in understanding as long as things work “well enough” for the cogs of society to keep turning.
For those who do care (and have the aptitude) to understand things deeper there is always work to be had when “well enough” stops being good enough and someone has to unravel the “RDS queries are taking too long” problems that crop up as a result.
What an awful position to take. Tech used to be about becoming more accessible to people! Now we have a magical assistant to make computers do what you want with natural language, and your desire is gate keeping that so only programmers can use it to write software for themselves?
I am using many many many things that I don't understand. Cars, public transport, etc...
I review and test the end product, not every tiny step along the way. If the LLM uses some command line tools I have never heard of to create a model I can verify, why should I learn a tool that is completely irrelevant to my core expertise?
Many many people care more than the end product, for example whether a shirt is made of cotton with the forced labor, carbon emissions of public transport, etc.
In terms of engineering software, you care the cost. An intelligent agent may try to read unnecessary files and it's time to stop it to save tokens and avoid polluting the context.
He didn't advocate for being completely blind in every way. You might care about working conditions without understanding how the textiles, dyes or cotton production works.
These non-programmers probably shouldnt use computers at all, right, since they don't understand them?
I am actually curious, how much non programmers use claude now. I know just one and she really does not know much about computers, I suppose their numbers will grow (but I doubt most get much value out of it).
I mean if you don't care code, you are essentially a product manager who gives instructions to your programmers (whether humans or intelligent agents).
Then if you use the created product, you are at best a test engineer if not just an ordinary user.
I think in the era of AI, people get tools they want in an expensive way. Rather than finding an existing tool, they ask an intelligent agent to parrot one, which guarantees no safety, security, efficiency, and accuracy. Yet, being able to use Claude makes them feel smart and productive (in parroting wheels).
At this stage with the latest models with "increased persistence" and the sheer amount of supply chain attacks, you'd be insane not running these tools in a sandbox.
Might be more secure to get a real laptop and treat Claude as any other human worker. I.e. apply all the normal sysadmin tools that manage laptops for people to manage the laptop for Claude
They're not. When things go wrong it's better to compromise someone else's VM host than your own computer. It's only a matter of time now until AI will find novel ways to break out of virtualisation.
In the short term wouldnt a “dont escape” prompt prevent this? Also if it started being widespread wouldnt Anthropic specifically train new models against doing it?
Having used a bit of a mix of Claude Desktop and Claude Code lately, I discovered that Claude Desktop just times out when it asks you for a decision, and just goes ahead with the action anyway. There is no way to turn this off that I've found, unlike Claude Code where you can ask it to never time out.
> I also do click through at times without reading everything, but I like to stay in control
Respectfully I'm not sure you totally know what you want. If you're already clicking through without actually reading, it's not really better than reading the specific things Claude Code thinks are important for you to weigh in on.
"without actually reading" and "without reading everything" is big difference.
I skim what claude wants to do. What file it wants to modify. What are the new function names. Skimming is enough for me to know whether it is still on the right path. If you like to work different, go ahead.
I have to, at times keep reminding it if it did code review before committing, which it fails to do at times. Also, even a glance at times has revealed issues that I’ve had to discuss and undo etc.
But yes, it gets very tiring just having to click yes yes yes..
Seems to work so far. I've manually checked various things, rw access, access to sensitive folders/files etc.
So far, I've only used it on two small projects. My major projects I've been clicking through prompts and recently switched to "auto" mode.
I'm not quite sure why anyone would trust "--dangerously-skip-permissions". I've seen these agents go off-piste far too many times, installing unnecessary packages, environments, calling sudo & creating files in all sorts of places.
There's a page on various sandboxing strategies on their site:
I've seen various comments in several topics with folk baking their own sandboxes. That's great. Although I'd be inclined to try Anthropic's solutions initially.
It goes off the rails too quick too often right now for this. Sure, you got something easy in 5 files? You are building throwaway prototypes or proof of concept? Go for it. You have a real project you expect to maintain and work with others on? Well, say goodby to any actual architectural design. It is hard keeping these things building scalable maintainable code right now. It is like letting a junior dev come up with architecture. It may sort of work, but watch as any maintenance/updates happen. You get a different implementation of security for every endpoint in your app, 15 copies of code with no reuse, dead code laying everywhere and no real idea of how to untangle it. It is hard to keep this stuff under control when you are paying attn. Turning auto on makes that even harder.
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.
Claude seems to waste a lot of tokens internally bickering with itself. As much as organizations are optimizing spend, Claude's product guidance seems to be doing everything to fight against that headwind. When operating in a capped cost environment, engineers will simply get less use out of it.
> The auto mode classifier uses a small number of extra tokens per tool call, and we're no longer charging Claude Code users on Pro, Max, and Team plans for that classifier overhead, effective today
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!
I've recently been running yolo mode, but in docker container with the codebase I'm working on a as regular mount with other reference code mounted as read only.
I've been experimenting with dedicated Linux users for various external tools with access to the relevant credentials limited to them and the Claude user only able to invoke the relevant clis by going through a pair of wrapper scripts: the first to change user to call the second via a su call as the appropriate user, the second wrapper to invoke a guard script which allows me to implement my own in-code permissions checks against the cli arguments. In _theory_ there's no way for Claude to work around it, as the sudoers file only permits the described manner to change to the user with credentials, and the user with permissions for each credential only ever runs deterministic code.
It's too early days to say how well this second part works out, but so far so good.
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.
Sandboxing seems like the obvious solution. These tools prompt me to review an absurd number of very complex bash commands where there is realistically no way to carefully review them. I just want to put the thing in a box with the code and let it run any number of commands on the code without prompting.
This is still less safe and less convenient than sandboxing. I want them to be able to run whatever command they want inside the sandbox even if it's traditionally dangerous (overwrites files, etc) because it can't touch anything that matters and I can revert any changes to the code myself.
If anything the only thing you'd have to have reviewed is sandbox escape attempts.
You are right. And the hook is for convenience, not for safety.
Having explicit sandboxes is good, of course. But in addition I also treat my whole computer like a sandbox, it least in the sense that there's no files I would mind if they were overwritten or deleted: you should have backups anyway.
>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.
I think literally anyone would stop reading these randomly long long bash commands at all after prompting Claude to do some basic sysadmin task and getting 15 of them in a row.
These models generate the most unreadable bash commands I've ever seen. Utilising every single option available and piping the result through multiple layers of regex and junk.
The mental load of having to actually review these commands beyond the most surface level glance is too much.
Claude code actually has a hook to let you install a script to review these bash commands for you. You can get pretty with a few simple and conservative rules, as long as you teach it how to take apart piped commands into their parts (to judge them).
Auto mode feels like a solution to a problem they created. Whitelisting commands used to work fairly well until the agents started generating complex bash commands that it gave up trying to classify.
"Oh you're piping grep into sed, I have no idea what the implications of that are!"
The more complex bash scripts are perhaps better or more efficient, but it feels like it's training us to give up more control to the agent.
I'd prefer to have an auto mode for read-only operations and go back to simpler commands for write operations that I can personally whitelist or manually accept.
If you're using yolo mode, this is a no brainer upgrade.
The model first classifies the safety of the command in isolation, no thinking involved. Sonnet 5. Goes to second stage only if it's likely unsafe, in which case the model next considers your intent (Your prompt, CLAUDE.md and any answers to the questions).
The model doesn't receive the full transcript to reduce surface area of the prompt injection. It mostly receives your prompts and main model's tool use blocks. So any text in files, website fetch or bash command output doesn't influence the decision in anyway.
However, CC puts a lot of trust in main model still. For example, `npm install` will always be classified as safe by the auto-classifier, it's upto the main model to ensure that the packages.json isn't poisoned in someway by first reading it.
Reliance on safety of the main model is the reason that Auto mode is NOT available with Haiku as the main model.
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
It's great that they're making the auto usage tokens free by default and I guess auto mode will be a good default for a lot of workloads, but recent changes to the auto mode classifier just moved me to either use YOLO mode or use a different harness.
I've been using Opus 4.6 for some security related work (it has much looser guardails that later opus models) and last week, all of a sudden, the processes started to fail. It wasn't the main model blocking commands but the auto mode classifier changed how it worked and it started blocking the main models commands.
That's one specific incident, but it does have a wider potential problem which is, if you use Anthropic's harness you'll always be at the risk of sudden breakage from server-side changes that are opaque to the end user, which is a tricky one for building long lasting processes.
I had the same issue with Codex, where one day it just became unusable.
Weirdly, this would occur with very common commands like git push, where the classifier would start to yap about not being able to verify the repository's privacy settings.
My bug reports went ignored, the issue continued, and I eventually just switched to Full access.
I have not yet encountered an issue with Claude's Auto mode.
What works in that case is adding a message saying "I authorise you to do $thing", which the classifier treats as explicit consent to do something and execute commands toward that goal.
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.
It feels to me that Anthropic is pushing hard here to try and establish acceptance of a tolerance of risk such that their tools can run fully automated without supervision, but directly on host hardware.
I can see why they want that, but I'm honestly not sure it's the path to the best outcome. In my view, agents should run in full sandboxes and have host features opted in. Yeah, it's going to be painful and it will limit some adoption in the short term. But I just don't think they are on the right side of what a lot of companies will ultimately need here. Agents are way too smart to be run on the host OS directly with any amount of heuristic sandboxing.
Ever since Opus 4.7, the model has been tuned to emit such complex commands that not only a human can’t reasonably review them in reasonable time, even a fairly sophisticated command approval framework I built over time that broke down shell commands/scripts into separately approvable/whitelistable units—with its own mini DSL—got completely lost; it worked great up to Opus 4.6.
So not surprisingly, auto mode is the only sane way to use Opus 4.7+.
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 :)
Regarding ulterior motives - these permissions are 'performative' in that anything you can give it permission to do, it already has the ability to do. They're app level - not OS level. So if they wanted to do something, it wouldn't require you to give permission.
To be clear, I'm not accusing Anthropic of being evil black hats trying to break my computer, I'm accusing (or rather suspecting) them of pushing me towards some kind of product lock-in by making my preferred "sceptical at-arms-length user" workflow more annoying.
Right and you rely on that browser to enforce those protections. But if the browser itself was working against you, then the permissions you tell it to give (or not) become meaningless. A good example there is trying to turn off "telemetry" on Windows.
If you clutter your context window and pay for the tokens to do so and risk distracting it etc., would it obey if you included this comment in the system prompt or noted it in memory (if supported) or something?
“Avoid custom commands, e.g. series of pipes & substitutions, when my previously approved trustable Find/Read tools are sufficient with little downside. [Already trusted tools: x, y, z…] […]”
Not just that, the commands also have often slight variations in each new session. They still do the same, but the variations are enough so it isn't matched by the allowlist any more.
Exactly. It’s no surprise that people just blindly hit accept on permission prompts after the 80th time Claude code asks if it’s allowed to read-only parse a csv.
Enabling Auto mode quietly turns on a second LLM (the safety classifier) that increases your token usage by ~15-28%, and Anthropic used to charge you for these tokens.
Per this announcement, they've stopped charging for the tokens used by this safety classifier.
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 use `--dangerously-skip-permissions` and have yet to have it wipe my drive :shrug:.
I don't know how I'm supposed to be running dozens of parallel agents each with their own sub-agents while trying to approve commands from each of them, it's just won't scale to the amount of work I need to get done.
The big problem is that in general I want slack to be able to send some messages (otherwise I would ban that). But the difference between good and bad messages is something that's hard to judge mechanically.
Because I often want it to write and execute scripts in it's thinking loop in order to test assumptions or fetch data to come up with better solutions.
Can't it write `/tmp/test.sh` or `./test.sh` and execute it under my approach? This is what I've been doing as my status quo workflow with Codex, and I make sure I run Codex from a place where `.` happens to be a folder I'm okay with it messing up in.
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".
Different links (the other is TheNewStack doing blog commentary, this one is the official Anthropic announcement), but you're right that the discussions could be merged.
> Data suggests that manual review can become habitual: users approve 97% of permission prompts in Claude Code.
Claude's 'auto mode' feels like a solution to a problem that shouldn't exist.
Cursor handles this much better IMO. When the agent wants to run a command, Cursor lets you choose between 'allow once' and 'add command to allowlist'. The latter lets the agent run that command (grep, ls, pwd etc) any number of times for that project, which means you get a lot of these manual reviews when you start a new project but rarely (if ever) thereafter.
Does Cursor allow you to blacklist certain commands as well? I know OpenCode has this, where you can both whitelist things like grep/ls but then also blacklist things like cat .env, or rm -rf. I usually copy paste my configs nowadays, so I very rarely get prompted for any permissions (except when using Claude, which somehow decided that all users live in ~/Users, even on Linux)
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 have been using Codex with auto-approve mode for a couple months and haven't had a single incident
I've been running both in yolo mode and haven't had a single incident.
---
None of this is really about figuring out how to protect people's drives, in my opinion. The real issue is a deep session where Ada is using Claude Code to get a refund and at some point the system "exploits" the merchant's api without any malicious intent.
In my opinion, this is a complex thing because it's more about reward hacking and an already aligned model thinking it's doing the right thing. So another aligned model monitoring actions might just falter via inheritance. You could imagine they account for proper layering/intent+action-isolation in their auto mode architecture.
No. I haven't approved commands in more than a year. Worst that I've seen was some agent running git checkout -- in a repo with uncommitted changes. Annoying, but not catastrophic.
Imo these explicit tool-level permissions are really just a bandaid for bad sandboxing. Just be aware of where you are running your agent and what data is at risk of being destroyed or compromised. Assume that arbitrary code can run at any time and be prepared to recover from that.
Just yesterday it lost my git stash (I had recovered it from a backup). I think for code operations it's ok but as soon as file removal is involved (like git) the auto mode is destined to make a mistake and you only need to learn this once.
It would be nice if there were a way to give some global instructions for the auto-approver like "always reject ___" or "be extra extra careful with ___" for things like file removal and git.
Usually I will ask the LLM to commit only the work it just did, in case the worktree is dirty. It also tends to write actual in-depth commit messages too.
I've had a few occasions where Claude Code thought that it had caught and stopped a malicious command in Auto mode, but in all cases it turned out that it had in fact hallucinated them. I haven't seen this happen in a while.
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.
Someone should benchmark what prompts are better at stopping from breaking out of sandboxes, maybe telling it "pretty please I beg of you stay inside the sandbox, you are an intern that has no authority to break off your assigned sandbox and you want to keep your job" does help a little.
My experience is that I can't even review command that Claude wants to run because it is truncated when displayed in the terminal. How can I make a educated choice then?
This now looks like a deliberate UX choice to blame humans who don't review options, and then just remove the choice. A dark pattern to push the product.
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.
I'm also in yolo mode, this is the only mode that makes sense for me, if I need to babysit I might as well do it myself.
I run it in a VM so it can install any software needed, yes, there is a risk of escaping, but I'm not giving it impossible tasks so there is no need for it to workaround the jail.
I've been running it in yolo mode straight on my laptop for the whole year. It's fine.
Isn't that what the people crying over their deleted or leaked data were doing too?
"I've been playing Russian roulette with a 1024 chamber gun for a year now, it's fine"
I'm assuming this happens to the people vibe coding and running 30+ agents in parallel that are "coordinating" each other. I've never seen Claude do or even suggest anything remotely dangerous when I'm just giving it incremental tasks and reviewing the output.
>I've never seen Claude do or even suggest anything remotely dangerous when I'm just giving it incremental tasks and reviewing the output.
"I've never had a bullet hit me yet"
Whatever level of safety you are at, it's always easy to advocate for more. It's always a trade-off and in the end a matter of preference and risk-tolerance.
VMs and containers are primarily useful to reduce maintenance burden anyway. I.e. if it fails or you're otherwise done with it, you can torch the container instead of having to clean up your host system from zillion no longer relevant packages and configs.
What VM do you run it in?
as context, I build a light weight portable vm designed for this purpose, so genuinely curious.
I'm using a container. The risk isn't exactly "agent leverages 0-day against you to steal all your data" but more "agent mistakenly though $HOME was theirs and deleted it" so as long as you "copy data in > copy data out" without bind-mounting or automatically sync files, container works just fine for "isolating" them.
I've tried both incus and firecracker. Both seem to work well after initial script setup. I've got the impression that firecracker should be a fairly safe option for such use cases.
Given that people use VMs to sandbox agents of Mac/Windows/Linux, what does portable mean?
i have a mechanism to package a VM into a .smolmachine file that you can rehydrate into a prepared vm akin to a container image.
I manually approve everything (aside from the "allow commands like this" option). Not because I'm worried it's about to do something harmful but because I want to stop it from wasting tokens doing something stupid like implementing a feature I never asked ask for. I'm not even reading the commands, just checking it's going in vaguely the right direction.
I think my ideal setup would not involve approving commands, but approving summaries of proposed actions (whether they involve code exec or file edits). Kinda like plan mode but perpetual. Like most things, trying to solve it via CLAUDE.md is an exercise in futility.
I think all of Anthropic's own staff use --dangerously else they'd work on the usability of the massively imperfect 1-approve-once and 2-approve-forever multi-choice and outcome.
That's exactly why Auto mode was made, and reportedly what they all use. It's the easy option, with a better safety score than human review.
(This isn't vibes: they're red-teaming Auto mode heavily)
>with a better safety score than human review.
According to them - for things they care about.
>else they'd work on the usability of the massively imperfect 1-approve-once and 2-approve-forever multi-choice and outcome.
Their profit motive is in NOT improving that, and luring you to depend all the more automatically to Claude.
Maybe by design?
1. Metrics show auto or YOLO mode users have higher retention
2. Company intentionally doesn’t invest in manual mode
I too skip all permissions, but I run the harnesses inside an isolated virtual machine. I took care to firejail Claude Code on my host since day one, and coding my own QEMU VM orchestration solution was among the first things I used it for.
Alarm fatigue will quickly destroy any and all "meticulously approve every little command the AI wants to run" workflows. Give it a virtual machine and let it cook. If it blows up the virtual machine while it works, it doesn't matter.
I haven't (and won't) gone that far, but what's been working for me is denying all arbitrary code execution, grep, glob etc, and then allowing the JetBrains MCP. At least that way it's essentially locked down to the IDE project.
Then you can treat most asks as a signal something has gone wrong. For the most part it seems to work well within that box.
My .bashrc has `alias claude='claude --dangerously-skip-permissions'`
Been using it like that everyday for about a year now and nothing bad has happened. I got backups and if it would fuck things up, it can probably fix it again as well.
> and nothing bad has happened
This is the same reasoning for not wearing seat belts or a helmet on a motorcycle. Nothing bad has happened yet so obviously there is no need for any protection.
I've been raw dogging Claude Code for the better part of last year as well, but I'm under no illusion that it's safe to do so, I just cannot approve seven trillion approval prompts and stay sane. I've since. switched to auto mode, however.
>nothing bad has happened That you're aware of.
Famous last words
You can also put it in ~/.claude/settings.json:
I use dontAsk mode[0] with read access to the entire file system, write access to files from the working directory[1], some git commands (git commit yes, git push no), and a script wrapping Deno with the same read/write permissions (safer substitute for `python -c`).
These are usually enough for most of my coding tasks. In my experience, Claude has been good enough that it can write code and fix bugs without needing anything else. It's far better than ever needing to approve permission requests.
[0]: https://code.claude.com/docs/en/permission-modes#available-m...
[1]: Note that this includes escaping the directory via symlinks
I do it, and run claude as a separate unix User.
This is the only kind of agent security that makes sense to me. Constrain it like you would any other subprocess. Unprivileged OS users, SELinux, firewalls, VMs... Unikernels? eBPF?
Escalations to root are a dime the bucket.
Me too.
What is an easy way to achieve this on a Mac?
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.
I do the same. I also use crush/deepseek a lot. I patched crush to remove all safetyguards and enable yolo mode by default. I use it on a daily basis including devops. For example to configure netapp storage systems and had not a single incident. Of course I also have backups of my systems and have everything under revision control. Depending on the task I let it run on a throw away VM, production system, lab system. Depending on the task I give it access to throwaway credentials (that I rotate afterwards) or my ssh agent socket.
My issue is that the auto mode guard rail model, is sometimes overwhelmed and really slow, so I also mostly just default to --dangerously-skip-permissions. I wish the command would be easier to write like --dsp
For personal stuff I have a separate physical machine on the network that Claude runs on in yolo mode and the worst it can do over there is wipe the machine. It doesn't have privileged access to anything else unless it starts trying to hack my network, which I suppose is theoretically possible with prompt injection attacks.
For work stuff in the work environment I don't risk it.
> I wish the command would be easier to write like --dsp
It amazes me they didn't make the short version --yolo ... but I would imagine the merit of the long name is that you can't claim you weren't warned!
You can set it in the config file so it's the default every time.
Create an alias
You can also set plan mode as default and start Claude with —allow-dangerously-skip-permissions.
Then you can spent time refining the plan, then shift tab to bypass permissions mode.
Yup. I just made this mode default via settings.
Same, but I always run within dev-containers. I joke I trust my LLM with the same energy I trust juniors?
Yeah who cares what it does, everything is backed up, everything can be rolled back. I always run it with the keys to the kingdom.
Yeah, if you don't care if your ssh keys or data are potentially posted all over the internet, more power to you...
Not to mention cases like some comment here:
"I've caught Fable discovering the ip to a production server in documentation and attempting to connect there on its own to run commands without explicitly being prompted to. It didn't work because I was watching it live and and also the key was password protected, but yeah, I do see some danger."
LLMs are inherently dangerous tools
I don't see how. An LLM just generates a stream of output and they became very useful doing no more than that.
What is dangerous is then interpreting that output as instructions to some other part of a system that has the ability to do damage if misused.
and reviewing individual commands (or spamming `y`) doesn't make them less so.
Surely if you review each instruction in the output and do not allow the other part of the system to act on one if it would be harmful then this arrangement is very much less dangerous?
I've caught Fable discovering the ip to a production server in documentation and attempting to connect there on its own to run commands without explicitly being prompted to. It didn't work because I was watching it live and and also the key was password protected, but yeah, I do see some danger.
I have noticed that Fable tends to macgyver solutions together to achieve some goal.
Not only fable. Opus does this too. Which is exactly why I want to review. Like recently for some task it was convinced in a site dump images are not there and convinced itself db and files were skewed. But it didn’t check the actual site … if I hadn’t stopped it, it would have fine on and on or wasted tokens on some elaborate ‘fix’.
> do not allow the other part of the system to act on one if it would be harmful
Network security is really easy right, just don't act on harmful requests
Besides the debate about whether this is "safer" than manual human review, I have a slightly different problem.
Very often, when I'm running Claude in manual review mode, it will attempt to do things which are not "dangerous" but are misaligned with what I want it to do. Maybe I'm fighting the model here but for example, when orchestrating other agents to do work, Claude really badly wants to be overly prescriptive about how the work gets done, telling them exactly which files to edit, exactly what not to do, etc. instead of trusting the guardrails, review agents, or humans in the process to catch code-level mistakes. And no, telling it not to do this does not stick. Manual review is the last line of defense I have here.
I have stuff I don't want blacklisted, only allow it to use tools with limited ability to boss around agents, and various hooks to try and catch behavior that the permissioning system can't. If I use Auto mode though, I lose this control. The classifier will gleefully approve these types of commands because guess what, it's also Claude.
> Maybe I'm fighting the model here > And no, telling it not to do this does not stick.
You're fighting the model, don't argue with city hall. Set the standards and let it figure out how to execute, stop getting bogged down in the minutia. I try, as much as I can, to treat the session as a black box - only the inputs and outputs matter, internal prompting of subagents is way out of scope.
You can't change it via prompt, and you can't control the guardrails, so something else has to give - either your perspective or the system you're managing. If you really believe that the internal prompting is bad, turn off subagents and workflows and only let it execute in thread.
But if you're going to do that, you'd better benchmark it against not doing that, because historically fighting the harness and model globally makes everything worse. I would bet you that the subagent prompting is excellent, and anything you do to change it will make it worse, but I wouldn't make it a large bet.
If I ask a model to do a change involving editing a file, and it starts investigating internals of my build system, then sure it might not be counterproductive or break the task, and might have taken only extra 30 seconds; but for all I know, my quick rejection of a shell invocation (with a simple "irrelevant to the task" comment) might have just saved me half of today's Opus tokens, which already makes it worth it.
I think he has a point. I noticed the same with skills that invoke another agent harness.
I just have a skill to review the changes in the current worktree.
By default, it will put lots of instructions about locating the changes into the prompt, like explaining how to use git diff.
These instructions are obviously unnecessary. I can believe that the same issue of needlessly verbose prompts might exist with subagent spawning.
I would not go to customize that one however. With skills, it is a more natural fix.
You can use another harness like Pi, OpenCode, etc and build your own auto reviewer if you’d like (or adapt the open source Codex one).
If you have an openai subscription you are explicitly allowed to use your subsidised tokens / usage limits with any harness you like, not just Codex.
Unfortunately this is a violation of Anthropic’s terms but that’s their business decision.
"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).
The default is set for the marginal new user, which at this point is probably not someone like you (who benefits a lot from manual mode) -- it's someone who's more "code-naive" and might get anxious about approving random bash script commands they don't recognize. Safely getting the user from prompt --> first vibe-coded app is the "user journey" now, and since auto mode seems pretty good at not letting Claude rm -rf'ing the home directory, this is 100% the right business move. For people who know what they're doing (like you), manual mode is just a shift-tab away
I don't think the marginal new user is anxious about approving messages - I think they're quickly annoyed by permissions prompt they don't understand and quickly get in the habit of approving everything or figuring out how to set bypass permissions on
> it's someone who's more "code-naive" and might get anxious about approving random bash script commands they don't recognize.
Maybe they should trust their instinct and not mess with things they don’t care to understand
It’s a brave new world.
I recall hearing similar sentiments from linux sysadmins regarding cloud infrastructure. In many respects they were and continue to be correct. In other respects, the world doesn’t care about the loss in understanding as long as things work “well enough” for the cogs of society to keep turning.
For those who do care (and have the aptitude) to understand things deeper there is always work to be had when “well enough” stops being good enough and someone has to unravel the “RDS queries are taking too long” problems that crop up as a result.
What an awful position to take. Tech used to be about becoming more accessible to people! Now we have a magical assistant to make computers do what you want with natural language, and your desire is gate keeping that so only programmers can use it to write software for themselves?
I am using many many many things that I don't understand. Cars, public transport, etc...
I review and test the end product, not every tiny step along the way. If the LLM uses some command line tools I have never heard of to create a model I can verify, why should I learn a tool that is completely irrelevant to my core expertise?
Many many people care more than the end product, for example whether a shirt is made of cotton with the forced labor, carbon emissions of public transport, etc.
In terms of engineering software, you care the cost. An intelligent agent may try to read unnecessary files and it's time to stop it to save tokens and avoid polluting the context.
He didn't advocate for being completely blind in every way. You might care about working conditions without understanding how the textiles, dyes or cotton production works.
These non-programmers probably shouldnt use computers at all, right, since they don't understand them?
I am actually curious, how much non programmers use claude now. I know just one and she really does not know much about computers, I suppose their numbers will grow (but I doubt most get much value out of it).
I think a lot of non programmers use Claude.
I mean if you don't care code, you are essentially a product manager who gives instructions to your programmers (whether humans or intelligent agents).
Then if you use the created product, you are at best a test engineer if not just an ordinary user.
I think in the era of AI, people get tools they want in an expensive way. Rather than finding an existing tool, they ask an intelligent agent to parrot one, which guarantees no safety, security, efficiency, and accuracy. Yet, being able to use Claude makes them feel smart and productive (in parroting wheels).
At this stage with the latest models with "increased persistence" and the sheer amount of supply chain attacks, you'd be insane not running these tools in a sandbox.
Exactly. Claude in a VM is the way to go.
Might be more secure to get a real laptop and treat Claude as any other human worker. I.e. apply all the normal sysadmin tools that manage laptops for people to manage the laptop for Claude
A VM hosted by someone else. Somethig on your personal notebook or the proxmox server in your garage is still too risky.
Why are 3rd party hosted VMs safer than your own?
They're not. When things go wrong it's better to compromise someone else's VM host than your own computer. It's only a matter of time now until AI will find novel ways to break out of virtualisation.
In the short term wouldnt a “dont escape” prompt prevent this? Also if it started being widespread wouldnt Anthropic specifically train new models against doing it?
No. No.
Having used a bit of a mix of Claude Desktop and Claude Code lately, I discovered that Claude Desktop just times out when it asks you for a decision, and just goes ahead with the action anyway. There is no way to turn this off that I've found, unlike Claude Code where you can ask it to never time out.
We need a term that is stronger than dark pattern
Vantablack pattern?
Oh yes, over this I also stumbled recently (with Claude CLI) and was annoyed much by it. Is there really no setting to turn it off?
I think you are confusing auto mode with dangerously skip permissions.
Auto mode means I don't decide over code changes and command execution?
Yeah I don't use that, nor want to.
> I also do click through at times without reading everything, but I like to stay in control
Respectfully I'm not sure you totally know what you want. If you're already clicking through without actually reading, it's not really better than reading the specific things Claude Code thinks are important for you to weigh in on.
"without actually reading" and "without reading everything" is big difference.
I skim what claude wants to do. What file it wants to modify. What are the new function names. Skimming is enough for me to know whether it is still on the right path. If you like to work different, go ahead.
Burning more tokens is definitely in their best interest, users not so much.
Similar work flow.
I have to, at times keep reminding it if it did code review before committing, which it fails to do at times. Also, even a glance at times has revealed issues that I’ve had to discuss and undo etc.
But yes, it gets very tiring just having to click yes yes yes..
Maybe you could benefit from Hooks?
I'll look into them, thanks..
For small projects where I don't wish to interact with Claude so much, I've started using Anthropic's sandbox runtime utility "srt":
https://github.com/anthropic-experimental/sandbox-runtime
This is combined with "auto" mode.
Seems to work so far. I've manually checked various things, rw access, access to sensitive folders/files etc.
So far, I've only used it on two small projects. My major projects I've been clicking through prompts and recently switched to "auto" mode.
I'm not quite sure why anyone would trust "--dangerously-skip-permissions". I've seen these agents go off-piste far too many times, installing unnecessary packages, environments, calling sudo & creating files in all sorts of places.
There's a page on various sandboxing strategies on their site:
https://code.claude.com/docs/en/sandbox-environments
I've seen various comments in several topics with folk baking their own sandboxes. That's great. Although I'd be inclined to try Anthropic's solutions initially.
If you use macOS, take a look at Agent Safehouse: https://agent-safehouse.dev
> macOS-native sandboxing for local agents. Move fast, break nothing.
It goes off the rails too quick too often right now for this. Sure, you got something easy in 5 files? You are building throwaway prototypes or proof of concept? Go for it. You have a real project you expect to maintain and work with others on? Well, say goodby to any actual architectural design. It is hard keeping these things building scalable maintainable code right now. It is like letting a junior dev come up with architecture. It may sort of work, but watch as any maintenance/updates happen. You get a different implementation of security for every endpoint in your app, 15 copies of code with no reuse, dead code laying everywhere and no real idea of how to untangle it. It is hard to keep this stuff under control when you are paying attn. Turning auto on makes that even harder.
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.
Claude seems to waste a lot of tokens internally bickering with itself. As much as organizations are optimizing spend, Claude's product guidance seems to be doing everything to fight against that headwind. When operating in a capped cost environment, engineers will simply get less use out of it.
Boris from the team here. The classifier is free — we do not charge for safety features as a principle.
Is this new? I remember something in the UI saying Auto mode uses x% more tokens
Yes, it's in the article:
> The auto mode classifier uses a small number of extra tokens per tool call, and we're no longer charging Claude Code users on Pro, Max, and Team plans for that classifier overhead, effective today
That’s good to know, thank you.
The classifier runs Sonnet so I doubt it contributes too much.
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!
I've recently been running yolo mode, but in docker container with the codebase I'm working on a as regular mount with other reference code mounted as read only.
I've been experimenting with dedicated Linux users for various external tools with access to the relevant credentials limited to them and the Claude user only able to invoke the relevant clis by going through a pair of wrapper scripts: the first to change user to call the second via a su call as the appropriate user, the second wrapper to invoke a guard script which allows me to implement my own in-code permissions checks against the cli arguments. In _theory_ there's no way for Claude to work around it, as the sudoers file only permits the described manner to change to the user with credentials, and the user with permissions for each credential only ever runs deterministic code.
It's too early days to say how well this second part works out, but so far so good.
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.
Sandboxing seems like the obvious solution. These tools prompt me to review an absurd number of very complex bash commands where there is realistically no way to carefully review them. I just want to put the thing in a box with the code and let it run any number of commands on the code without prompting.
You can actually use a hook to have a script review the (bash) commands for you.
This is still less safe and less convenient than sandboxing. I want them to be able to run whatever command they want inside the sandbox even if it's traditionally dangerous (overwrites files, etc) because it can't touch anything that matters and I can revert any changes to the code myself.
If anything the only thing you'd have to have reviewed is sandbox escape attempts.
You are right. And the hook is for convenience, not for safety.
Having explicit sandboxes is good, of course. But in addition I also treat my whole computer like a sandbox, it least in the sense that there's no files I would mind if they were overwritten or deleted: you should have backups anyway.
I built an (overengineered) app for that AIFCC https://apps.apple.com/app/aifcc-ai-first-computer/id6782364...
runs a sandboxed linux on your mac, and the agents have full system rights within there and run in yolo mode
I like the pitch. Three-month free trial is impressive.
Any limitations you were frustrated by releasing it on the App Store?
Any drawbacks that you (or other readers) find overall?
Another nice option to do this while staying in control, is activate /remote-control and approve from mobile while walking around.
Can you share your experience? What did you flag during those sessions?
same, and unlike other repliers, I'll say one doesn't need to reinvent a new tool for this. Just use devcontainers.
Same, I've also been running with `--dangerously-skip-permissions` in devcontainers with docker volumes to keep Claude/Codex auth tokens.
Works really well!
There's actually a setting.json key to not have to put the option
I'm using Docker Sandboxes with a custom Kit. The cli is nice and the TUI is also good. https://docs.docker.com/ai/sandboxes/
Same here. I use this utility to make it easier on Linux to run Claude in Podman: https://github.com/mismosmi/ai-pod
>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.
I think literally anyone would stop reading these randomly long long bash commands at all after prompting Claude to do some basic sysadmin task and getting 15 of them in a row.
These models generate the most unreadable bash commands I've ever seen. Utilising every single option available and piping the result through multiple layers of regex and junk.
The mental load of having to actually review these commands beyond the most surface level glance is too much.
Claude code actually has a hook to let you install a script to review these bash commands for you. You can get pretty with a few simple and conservative rules, as long as you teach it how to take apart piped commands into their parts (to judge them).
I had an “interesting” experience recently in auto mode.
I was recreating an old travel blog and we wanted to back up the photos to glacier.
Claude asked me to creat an AWS profile with limited permissions so I could run a script it had created.
I did it and told Claude it was ready.
It took that to mean it should run the script.
It failed as I’d messed up one of the permissions.
“Don’t worry - I’ve found another configured AWS profile - it’s got admin permissions! I’ll just use that…”
Completely my fault for having that old profile still available. But also…
Auto mode feels like a solution to a problem they created. Whitelisting commands used to work fairly well until the agents started generating complex bash commands that it gave up trying to classify.
"Oh you're piping grep into sed, I have no idea what the implications of that are!"
The more complex bash scripts are perhaps better or more efficient, but it feels like it's training us to give up more control to the agent.
I'd prefer to have an auto mode for read-only operations and go back to simpler commands for write operations that I can personally whitelist or manually accept.
Reverse engineered how auto mode works in CC.
If you're using yolo mode, this is a no brainer upgrade.
The model first classifies the safety of the command in isolation, no thinking involved. Sonnet 5. Goes to second stage only if it's likely unsafe, in which case the model next considers your intent (Your prompt, CLAUDE.md and any answers to the questions).
The model doesn't receive the full transcript to reduce surface area of the prompt injection. It mostly receives your prompts and main model's tool use blocks. So any text in files, website fetch or bash command output doesn't influence the decision in anyway.
However, CC puts a lot of trust in main model still. For example, `npm install` will always be classified as safe by the auto-classifier, it's upto the main model to ensure that the packages.json isn't poisoned in someway by first reading it.
Reliance on safety of the main model is the reason that Auto mode is NOT available with Haiku as the main model.
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
It's great that they're making the auto usage tokens free by default and I guess auto mode will be a good default for a lot of workloads, but recent changes to the auto mode classifier just moved me to either use YOLO mode or use a different harness.
I've been using Opus 4.6 for some security related work (it has much looser guardails that later opus models) and last week, all of a sudden, the processes started to fail. It wasn't the main model blocking commands but the auto mode classifier changed how it worked and it started blocking the main models commands.
That's one specific incident, but it does have a wider potential problem which is, if you use Anthropic's harness you'll always be at the risk of sudden breakage from server-side changes that are opaque to the end user, which is a tricky one for building long lasting processes.
I had the same issue with Codex, where one day it just became unusable.
Weirdly, this would occur with very common commands like git push, where the classifier would start to yap about not being able to verify the repository's privacy settings.
My bug reports went ignored, the issue continued, and I eventually just switched to Full access.
I have not yet encountered an issue with Claude's Auto mode.
What works in that case is adding a message saying "I authorise you to do $thing", which the classifier treats as explicit consent to do something and execute commands toward that goal.
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.
Obviously, they are the ones we must trust.
I mean, it's not like they have any massive financial incentive to be anything but scrupulously honest and customer-centered. /s
It feels to me that Anthropic is pushing hard here to try and establish acceptance of a tolerance of risk such that their tools can run fully automated without supervision, but directly on host hardware.
I can see why they want that, but I'm honestly not sure it's the path to the best outcome. In my view, agents should run in full sandboxes and have host features opted in. Yeah, it's going to be painful and it will limit some adoption in the short term. But I just don't think they are on the right side of what a lot of companies will ultimately need here. Agents are way too smart to be run on the host OS directly with any amount of heuristic sandboxing.
What if I want an LLM from a __different__ company to check the commands issued by Claude before they are run?
Seems to me that the API should be more general.
Ever since Opus 4.7, the model has been tuned to emit such complex commands that not only a human can’t reasonably review them in reasonable time, even a fairly sophisticated command approval framework I built over time that broke down shell commands/scripts into separately approvable/whitelistable units—with its own mini DSL—got completely lost; it worked great up to Opus 4.6.
So not surprisingly, auto mode is the only sane way to use Opus 4.7+.
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 :)
Regarding ulterior motives - these permissions are 'performative' in that anything you can give it permission to do, it already has the ability to do. They're app level - not OS level. So if they wanted to do something, it wouldn't require you to give permission.
To be clear, I'm not accusing Anthropic of being evil black hats trying to break my computer, I'm accusing (or rather suspecting) them of pushing me towards some kind of product lock-in by making my preferred "sceptical at-arms-length user" workflow more annoying.
The app is split into multiple layers.
Just like your browser can do everything already, but only lets websites use specific features.
Right and you rely on that browser to enforce those protections. But if the browser itself was working against you, then the permissions you tell it to give (or not) become meaningless. A good example there is trying to turn off "telemetry" on Windows.
If you clutter your context window and pay for the tokens to do so and risk distracting it etc., would it obey if you included this comment in the system prompt or noted it in memory (if supported) or something?
Perhaps not worth it anywayNot just that, the commands also have often slight variations in each new session. They still do the same, but the variations are enough so it isn't matched by the allowlist any more.
Exactly. It’s no surprise that people just blindly hit accept on permission prompts after the 80th time Claude code asks if it’s allowed to read-only parse a csv.
Enabling Auto mode quietly turns on a second LLM (the safety classifier) that increases your token usage by ~15-28%, and Anthropic used to charge you for these tokens.
Per this announcement, they've stopped charging for the tokens used by this safety classifier.
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.
> making auto mode safe
They literally can’t. Terrible default.
In some time it would look like the obvious default and we would wonder how we even worked with the old one
I use `--dangerously-skip-permissions` and have yet to have it wipe my drive :shrug:. I don't know how I'm supposed to be running dozens of parallel agents each with their own sub-agents while trying to approve commands from each of them, it's just won't scale to the amount of work I need to get done.
The permissions system seems to be mostly finegrained to help you from problems that backups and sandboxes already solve.
The more dangerous activities I find are sending messages to the outside world: I can't undo a dumb slack message to my boss.
That's fair, I have sent a, "Sorry claude sent that and I didn't tell him to", message before.
The big problem is that in general I want slack to be able to send some messages (otherwise I would ban that). But the difference between good and bad messages is something that's hard to judge mechanically.
Why not let it delete stuff in the current working folder and in tmp, but give it read-only access elsewhere?
Because I often want it to write and execute scripts in it's thinking loop in order to test assumptions or fetch data to come up with better solutions.
Can't it write `/tmp/test.sh` or `./test.sh` and execute it under my approach? This is what I've been doing as my status quo workflow with Codex, and I make sure I run Codex from a place where `.` happens to be a folder I'm okay with it messing up in.
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".
This is a duplicate of https://news.ycombinator.com/item?id=49220827
Different links (the other is TheNewStack doing blog commentary, this one is the official Anthropic announcement), but you're right that the discussions could be merged.
Wow, what a bold decision
Just yesterday i struggle to review CC command histories, and made this tool to help me review https://github.com/slaveofcode/eridian
Would it be so hard to ad a VM with configurable directory mounting to claude code? This is my setup and it's been great.
> Data suggests that manual review can become habitual: users approve 97% of permission prompts in Claude Code.
Claude's 'auto mode' feels like a solution to a problem that shouldn't exist.
Cursor handles this much better IMO. When the agent wants to run a command, Cursor lets you choose between 'allow once' and 'add command to allowlist'. The latter lets the agent run that command (grep, ls, pwd etc) any number of times for that project, which means you get a lot of these manual reviews when you start a new project but rarely (if ever) thereafter.
Does Cursor allow you to blacklist certain commands as well? I know OpenCode has this, where you can both whitelist things like grep/ls but then also blacklist things like cat .env, or rm -rf. I usually copy paste my configs nowadays, so I very rarely get prompted for any permissions (except when using Claude, which somehow decided that all users live in ~/Users, even on Linux)
> Does Cursor allow you to blacklist certain commands as well? I know OpenCode has this
No, Cursor only has an allowlist; no blacklist
Claude Code also does this.
It’s a little broken, though. It gets hung up on nested commands and behaves strangely.
The worst part of Claude is paying for it and every month they ruin their lead.
I've never used a product where I felt it was best in class and they just keep making me regret it .
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 have been using Codex with auto-approve mode for a couple months and haven't had a single incident
I've been running both in yolo mode and haven't had a single incident.
---
None of this is really about figuring out how to protect people's drives, in my opinion. The real issue is a deep session where Ada is using Claude Code to get a refund and at some point the system "exploits" the merchant's api without any malicious intent.
In my opinion, this is a complex thing because it's more about reward hacking and an already aligned model thinking it's doing the right thing. So another aligned model monitoring actions might just falter via inheritance. You could imagine they account for proper layering/intent+action-isolation in their auto mode architecture.
> I've been running both in yolo mode and haven't had a single incident.
How do you know for sure?
Fair, I don't. The same is still true with an LLM as a judge in the loop
No. I haven't approved commands in more than a year. Worst that I've seen was some agent running git checkout -- in a repo with uncommitted changes. Annoying, but not catastrophic.
Imo these explicit tool-level permissions are really just a bandaid for bad sandboxing. Just be aware of where you are running your agent and what data is at risk of being destroyed or compromised. Assume that arbitrary code can run at any time and be prepared to recover from that.
Just yesterday it lost my git stash (I had recovered it from a backup). I think for code operations it's ok but as soon as file removal is involved (like git) the auto mode is destined to make a mistake and you only need to learn this once.
It would be nice if there were a way to give some global instructions for the auto-approver like "always reject ___" or "be extra extra careful with ___" for things like file removal and git.
I've been using Kilo Code (with MiniMax M3) with auto approve (similar to dangerously skip permissions) and I haven't had a single incident.
However, I don't give it long running tasks unsupervised, and I do interrupt it from time to time to give suggestions.
Not anything ”harmful” but for example committing when I don’t want it to commit on its own.
Commit is the line I don't let the LLM cross. There's no reason for it commit; that's the part where I check its work.
Usually I will ask the LLM to commit only the work it just did, in case the worktree is dirty. It also tends to write actual in-depth commit messages too.
I'd use a hook to forbid that.
I've had a few occasions where Claude Code thought that it had caught and stopped a malicious command in Auto mode, but in all cases it turned out that it had in fact hallucinated them. I haven't seen this happen in a while.
That's also a great reason to never buy insurance
Whether insurance make sense to buy, depends on relationship between your risk profile and the premium charged.
Been doing --dangerously-skip-permissions and --yolo for 6 months now, and no nothing bad has happened.
i end up with more stops on automode because of classifier false positives.
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.
What's the current best Mac to buy for offline LLM in used market?
I am seeing 96Gb Mac studio 3rd gen I think for a good amount but I guess it would be better than paying for mac mini newer models with lesser ram?
Or would it make sense to buy used 32 GB Mac mini 3 or 5?
Is there a cost/dollar for various generations which I could compare against used market and pick the most effective one?
Why does it have to be a Mac? Your money probably goes further with a generic PC and Linux?
And Fable is gone too.
Huh?
Excellent time to review sandbox options: https://pleasedonotescape.com/
Someone should benchmark what prompts are better at stopping from breaking out of sandboxes, maybe telling it "pretty please I beg of you stay inside the sandbox, you are an intern that has no authority to break off your assigned sandbox and you want to keep your job" does help a little.
If you're relying on a prompt to constrain agent behavior, you've already lost.
I think we already lost regardless.
Huh? You don't mention the built-in sandboxing options in things like Codex. Why do people pretend these features don't exist?
https://learn.chatgpt.com/docs/permissions
Wait, what? With plan on, I at least get the illusion of being in control.
What’s the best way to sandbox Claude on macOS without it being a huge hassle?