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.

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.

"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).

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.

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.

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.

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!

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 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…

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.

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

6 months ago: get Claude to do some work, have GPT review it, ask Claude to first verify findings before actioning.

Now: get GPT to do some work, have Claude review it, question Claude about a finding that is surprising to me because I thought the functionality was already in place.

[Claude/Opus 5 Max goes looking] "You're right — I was wrong about that."

Our Claude license ends in about 2 weeks and we're not renewing - this has been par for the course for the last 2 months now.

And their marketing is really starting to bother me, on top of that.

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.

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.

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.

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.

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 :)

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.

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

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.

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.

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.

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

This is a duplicate of https://news.ycombinator.com/item?id=49220827

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

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.

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 .

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?

And Fable is gone too.

Excellent time to review sandbox options: https://pleasedonotescape.com/

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?

[flagged]

[flagged]

[flagged]

[flagged]

[dead]

[dead]