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

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

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.

I do it, and run claude as a separate unix User.

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

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.

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.

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.

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?