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.
It can't account for things that only come up during implementation. But you can explore much more of the design space in planning to reduce the opportunities for Claude to wander down the wrong path during implementation
The plans usually end up very long and verbose, and in my most vibe-y test project I stopped even reading them myself and instead just ask questions interactively. e.g. "what are the remaining unanswered design decisions", "which part is jankiest". It does work quite well although I don't know how I feel about it.
P.S. to any anthropic staff: The "chat about this" option in Plan mode is useful but also annoying. When I select it I want to take the next turn of the conversation myself, I don't want it to waste time "thinking" just for it to verbosely ask me what I want to chat about.
Your summary approval idea is interesting and feels maybe like a mini plan mode. My biggest frustration with the existing manual approval system is when Claude is exploring it gets tedious to approve each command. Being able to approve a block of commands or a mini plan AND have auto mode audit them for safety would probably be something I would consider for the expiration phase of my Claude use.
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 playing Russian roulette with a 1024 chamber gun for a year now, it's fine"
If LLM agent wants to get out of dedicated folder where it’s supposed to work and tries to run a command, ppl should be always cautious. In fact, it is a sort of # access on live data.
Sudo/# is nice as you don’t have to ask for permissions, but I would recommend to do it only when you are fresh, fed, and not under stress.
I remember few times that I “accidentally” deleted or changed stuff I wanted to have intact… (Somebody would say that it is a skill issue :) But it was always when I was in hurry.
"I've never had a bullet hit me yet"
The other day I caught Claude including a rm -rf equivalent (fs.rmdir({ recursive: true, force: true })) in my code, to clean up temporary directories. It was fine, but that kind of code is only one misconfigured environment variable away from blasting away your $HOME.
I don't. I manually check the code line by line before. And also run them in container anyway.
Probably using not-SOTA models, or on the lower reasoning levels, they tend to be a bit more tally-ho when it comes to destructive operations, especially in longer tasks as the agent gets worse and worse as the context grows. Suddenly running some stupid command seems like the right way to go, and then $HOME is gone.
as context, I build a light weight portable vm designed for this purpose, so genuinely curious.
(This isn't vibes: they're red-teaming Auto mode heavily)
Considering I went through a phase before I started using Claude Code where I'd eventually reach a point where I'd mindlessly approve ridiculously long command chains, I believe this.
As the article writes: "many users are clicking through reflexively rather than reviewing each command".
It's far better (for my working style, anyway) to have some external isolation/sandboxing, but leave the actual command approval to LLM.
According to them - for things they care about.
Their profit motive is in NOT improving that, and luring you to depend all the more automatically to Claude.
1. Metrics show auto or YOLO mode users have higher retention
2. Company intentionally doesn’t invest in manual mode
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.
"permissions": {
"defaultMode": "bypassPermissions"
},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.
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.
ofc, jails on bsd, containers , vms git backups and such techniques are a blessing, most risk is in the filesystem items being deleted . it wont suddenly hallucinate a kernel exploit or something extreme.
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
There is no perfect security.
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!
Then you can spent time refining the plan, then shift tab to bypass permissions mode.
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 wrap bubblewrap in a script that supports config files to allow different "profiles" of use (analogous to eg firefox profiles). The bwrap starts with the whole filesystem mounted read-only, then mounts the current directory read-write and then applies further bind mounts for devices, special case other read-write (eg, ~/.cache/) and to mount empties to cover sensitive directories (eg, ~/.ssh/). The profile also specifies the default command to run and for claude, it gets yolo mode.
Everything else you can sort of review what it did after the fact and/or tolerate mistakes, but knowing some thing’s are impossible for it to do us good peace of mind
Otherwise not sure who’d be willing to tediously on every single action on anything but the most important of projects, of which I can’t really think of any of that clear that bar for me
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."
A failed SSH connection to a staging server for example, can trivially make it look into .ssh to try to diagnose it. And many other ways, including prompt injection.
https://www.reddit.com/r/ClaudeAI/comments/1q7dszm/claude_al...
https://github.com/anthropics/claude-code/issues/31566
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?
It is the harnesses that some people are now wrapping around LLMs to interpret the output from a model as commands to run (or other executable instructions) that are creating all these new risks. Remember that this is still a very recent development and still more recently amplified by the use of feedback loops and long-running agents intended to operate with minimal human supervision.
It is going to be increasingly important to understand exactly what these tools are doing and why for both correctness and security reasons. Not conflating their capabilities with the underlying model that purely generates data is pretty fundamental here.
Network security is really easy right, just don't act on harmful requests