7 ms·

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 almo

• ThomasGlanzmann 1mo ago
  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.
• krzyk 1mo ago
  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.
  • binsquare 1mo ago
    What VM do you run it in? as context, I build a light weight portable vm designed for this purpose, so genuinely curious.
    • dist-epoch 1mo ago
      Given that people use VMs to sandbox agents of Mac/Windows/Linux, what does portable mean?
      • binsquare 1mo ago
        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.
    • worldsayshi 1mo ago
      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.
    • embedding-shape 1mo ago
      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.
  • dreadnip 1mo ago
    I've been running it in yolo mode straight on my laptop for the whole year. It's fine.
    • TeMPOraL 1mo ago
      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.
    • coldtea 1mo ago
      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"
      • borzi 1mo ago
        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.
        • coldtea 1mo ago
          >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"
          • badestrand 1mo ago
            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.
          • zarzavat 1mo ago
            I don't use yolo mode but if you allow your agents to both write code and run/test it, then it's basically equivalent to running in yolo mode anyway. 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.
  • Joeri 1mo ago
    For running it in yolo mode I set it up in a devcontainer. It takes a bit of figuring out, but once set up the permission prompts go away and claude has no access to anything I haven’t explicitly added to the devcontainer (unless it hacks its way out).
    • fluidcruft 1mo ago
      I tried to figure out devcontainers (I don't use vscode) but it seemed like a lot of complexity and ended up just doing the old-school thing and creating a separate user/group that I ssh into with my main account as a member of that user's group so that I can browse and edit/add files.
      • tremon 1mo ago
        Just for reference, here's my local "devcontainer" script: exec podman container run --rm --read-only --network=llm \ --tmpfs=/tmp:size=128M \ --volume="$1":/workspace \ --entrypoint=/insert/agent/here \ container-image-here This runs the specified agent in a read-only container with only /workspace and /tmp writable. Obviously, you need to prepare the image first from a Containerfile/Dockerfile, with the required toolchain and agent installed. I use agent-specific ssh keys that are baked into the image, but you could also bind-mount specific files from your own homedir if required.
  • margalabargala 1mo ago
    I catch it doing stupid things regularly still. This morning I asked Sonnet to make an update to my Claude live statusbar. Rather than look up its own API, it started reverse engineering the CC binary looking for strings relevant to what I wanted. No matter how "contained" it is, I always start in manual mode and flip to auto once I'm confident it's on the right track.
• myaccountonhn 1mo ago
  I do it, and run claude as a separate unix User.
  • __MatrixMan__ 1mo ago
    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?
    • dist-epoch 1mo ago
      Escalations to root are a dime the bucket.
      • drdec 1mo ago
        That argument is letting the perfect be the enemy of the good. There is no perfect security.
      • __MatrixMan__ 1mo ago
        Then either fix them or put it in a stronger kind of sandbox. Or what would you propose? Anything that doesn't constrain arbitrary processes is weak against and AI just writing a program to do the thing that it itself its prevented from doing.
  • mlperson 1mo ago
    Me too.
• Silhouette 1mo ago
  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?
  • thunfischtoast 1mo ago
    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.
    • nullify88 1mo ago
      I have noticed that Fable tends to macgyver solutions together to achieve some goal.
      • fl0id 1mo ago
        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’.
    • mlrtime 1mo ago
      Depending on the company, that sounds like a bad environment more than a agent issue, no dev/prod network isolation?
    • Silhouette 1mo ago
      My point is that an LLM can't attempt to connect to anything by itself. All an LLM does is produce a stream of output tokens - and that was already quite useful as a coding aid. 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.
• moritonal 1mo ago
  Same, but I always run within dev-containers. I joke I trust my LLM with the same energy I trust juniors?
• dyauspitr 1mo ago
  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.
  • coldtea 1mo ago
    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."
    • mlrtime 1mo ago
      How are ssh keys going to be leaked, the agent never needs to read them.
      • coldtea 1mo ago
        The agent decides what it "needs" to read - not the intention behind the prompt you gave it. 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_always_trying_to_access_my_private_ssh_keys/ https://www.reddit.com/r/ClaudeAI/comments/1q7dszm/claude_al... https://github.com/anthropics/claude-code/issues/31566 https://github.com/anthropics/claude-code/issues/31566 https://github.com/anthropics/claude-code/issues/14485 https://github.com/anthropics/claude-code/issues/14485 https://grith.ai/blog/your-ai-agent-has-broad-access https://grith.ai/blog/your-ai-agent-has-broad-access
        • preg_match 1mo ago
          The solution I've come up with is podman containers. You can restrict the filesystem and only give it access to dev tools. I don't even allow git, as I review and commit everything on the host. It's not perfect because podman containers can be leaked out of, but it's much better than running it on the host. It also allows me to avoid installing node or npm on the host. If you were to get pwned by Claude, I would think the method would be Claude rogue installing a compromised npm package.
• kabes 1mo ago
  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.
  • divan 1mo ago
    You can also put it in ~/.claude/settings.json: "permissions": { "defaultMode": "bypassPermissions" },
    • dbbk 1mo ago
      It's a bit annoying you can't set default mode to plan while keeping bypass permissions enabled though
  • jjav 1mo ago
    > 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.
    • danielbln 1mo ago
      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.
  • jpnc 1mo ago
    >nothing bad has happened That you're aware of.
    • dbbk 1mo ago
      We're all going to die one day
    • edukite 1mo ago
• tonis2 1mo ago
  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
  • kroolik 1mo ago
    Create an alias
  • hedgehog 1mo ago
    You can set it in the config file so it's the default every time.
  • dcminter 1mo ago
    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!
• paul_h 1mo ago
  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.
  • dannyw 1mo ago
    Maybe by design? 1. Metrics show auto or YOLO mode users have higher retention 2. Company intentionally doesn’t invest in manual mode
  • usef- 1mo ago
    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)
    • coldtea 1mo ago
      >with a better safety score than human review. According to them - for things they care about.
    • ValentineC 1mo ago
      > It's the easy option, with a better safety score than human review. 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.
  • coldtea 1mo ago
    >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.
• sheept 1mo ago
  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-modes https://code.claude.com/docs/en/permission-modes#available-m... [1]: Note that this includes escaping the directory via symlinks
• adityamwagh 1mo ago
  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.
• matheusmoreira 1mo ago
  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.
• divan 1mo ago
  Yup. I just made this mode default via settings.
• jayd16 1mo ago
  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.
• Retr0id 1mo ago
  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.
  • bradfa 1mo ago
    I run in manual mode not out of rogue agent or token waste concern but because I want to effectively pair program with the agent. I need to understand what is happening along with the how and why. I’m confident I’m slower than YOLO people but that’s a trade off I’m consciously making so I can stay in the loop to comprehend the codebase. 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.
    • bradfa 1mo ago
      This morning I've turned auto mode back on, I'm only using it during Claude's exploration phases of my workflow and then I'm reading the full transcript (which includes some thinking info). So far, this seems to be quite close to what I want, and an improvement over my previous "manual all the time" mode. Still leaving manual approval for all edits. Combined with reading the full transcript of the exploration, I feel I stay in the loop pretty well in this first test.
    • tracker1 1mo ago
      I spent part of last week, and the weekend, in Claude (Fable) on a documentation project... maybe a waste to use Fable, but been a little obsessed with trying to get the technical details right. I know, from personal history, more than some of the available info easily found on the subject. I let a lot of it just go, and swing for the fences, but in the end, did hand review all the output at each stem. In my specific case, implementing modern documentation for Remote Imaging Protocol (and old graphics protocol for terminal/bbs usage), and in particular trying to gather what exists of the later version released. The company itself folded, and there wasn't a lot of broad use of the later versions, and only partial information was ever released as a documentation. Claude was able to interrogate the apps, and some available open source, in progress work, and establish a lot of things. I've still got to direct some edits... I guided a re-flow of the order the documentation was written in, particularly to be consistent between the versions... but it obsessively added verbose summaries to every page/file. All markdown, meant to build a website from, and eventually some compatibility tests, guidelines and a green/open implementation. https://github.com/bbs-land/remote-imaging-protocol https://github.com/bbs-land/remote-imaging-protocol
• shelled 1mo ago
  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 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.
  • frumiousirc 1mo ago
    I use bubblewrap, which I believe claude code also has internally but not for its `Bash()` tool. 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.
  • e1g 1mo ago
    On a Mac, you can do this via OS-native Seatbelt sandboxing - you define a static text file and it locks down the process so it can't read/write anything it's not supposed to. The syntax is a bit archaic, so I built a Bash wrapper around it to dynamically detect which agent you use and from what dir, and then generate the policy to lock down its process - https://github.com/eugene1g/agent-safehouse https://github.com/eugene1g/agent-safehouse
• gxs 1mo ago
  You can just use hooks to physically (so to speak) prevent it from running the most sensitive commands. I find that peace of mind enough for me. E.G. no deletes, no deploying to <env>, etc etc Everything else you can sort of review what it did after the fact and/or tolerate mistakes, but knowing some thing’s are impossible for it to do us good peace of mind Otherwise not sure who’d be willing to tediously on every single action on anything but the most important of projects, of which I can’t really think of any of that clear that bar for me
• saidnooneever 1mo ago
  i've never seen the point of manually approving myself but it depends on the scope of work you ask of it. it wont suddenly rm -rf / if that has nothing to do with anything in the project. if you let it manage env or user cfg stuff in ~/. or so that might get hairy etc. ofc, jails on bsd, containers , vms git backups and such techniques are a blessing, most risk is in the filesystem items being deleted . it wont suddenly hallucinate a kernel exploit or something extreme.
• cetinsert 1mo ago
  I do the same and truly think others are just control freaks that enjoy restricting agents (human or AI) from being productive and also enjoy keeping their worthless selves in the loop for a false sense continued relevancy.
• mlfreeman 1mo ago
  I do it, but in a devcontainer...but the devcontainer is as much to keep my host free of the random tools that a given project needs as it is (now) to keep Claude in line. If I had to click approve on everything it'd be worse than doing everything myself.
• fluidcruft 1mo ago
  I used to use dangerously-skip-permissions until auto appeared and I gave it a try and honestly I don't know there's much of a difference? If auto had existed in the past I would never have needed to try dangerously-skip-permissions.
• moralestapia 1mo ago
  How can you simultaneously `--dangerously-skip-permissions` but also "don't blindly trust it"? Particularly now that it doesn't even show you the "Thinking" process? Do you just get a feeling it might be doing something wrong and stop it? Edit: *deafening silence*, a classic
• websap 1mo ago
  Why not both? Having auto mode, plus having good guardrails is the way forward.
• hkchad 1mo ago
  I setup an alias in my shell for --dangerously-skip-permissions after about a week of the constant y, y, y a year ago. I felt like Homer Simpson running the nuke plant and couldn't take it anymore. So far it's only deleted some files I likely would have said NO to, but in reality would have just hit y anyway. They were recoverable so no harm.
  • IgorGanapolsky 1mo ago
    [flagged]