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.
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).
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.
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.
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.
Every driver thinks of themselves they are an excellent ones. Statistics has another data :)
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.
> Every driver thinks of themselves they are an excellent ones. Statistics has another data :)
I think I'm an excellent driver, and I have data that backs that up, like I've never been in an accident but avoided plenty. What statistics show that I'm actually a terrible or even average driver?
> 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.
Gives me flashbacks to when the company I worked for had some issue in production, we were 3-4 people huddled around a laptop trying to figure out what was going wrong. Viewing the logs on the host itself was too slow or not possible somehow, can't remember the details, but we were able to start transfers of the logs out of the host. Only problem was that the log file was GBs long (what is log rotation?) so would have been too slow. Easy, just compress the log file, then send that, should be a lot smaller. Obviously we were all in a rush but still wanna be careful, so I enter the command for compressing the only log file we have, ask for someone to check, other person says "looks good to me", I hit enter and we get an error that it couldn't find the file we were trying to compress, the created archive been created without any entries added to it. The log directory is now completely empty, except one tiny "errors.log" zip/tar-file that had been created when we accidentally used the wrong order of the arguments in our command to create the compressed archive. I think we had to recreate the host at this point, reproduce the issue then get the logs again, probably slowing down recovery +30 min at least.
>I think I'm an excellent driver, and I have data that backs that up, like I've never been in an accident but avoided plenty. What statistics show that I'm actually a terrible or even average driver?
The statistics showing that past performance doesn't guarantee feature results, that a lot of the accident avoiding could be just having luck while still driving badly, and that a lot of drivers overestimate their skills.
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 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.
I've set up a second user on my machine just for running AI. That way I have the additional layer of OS protections against it doing something like that.
I run in auto permission mode and it will run with 1 task and end to completion. On the rare event it needs to rmdir or rm -r a dir, the permission mode will stop the agent. Sometimes annoyingly... so its more like. "I've never had a bullet hit me yet inside a office building on the 42nd floor".
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.
> Isn't that what the people crying over their deleted or leaked data were doing too?
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.
Zuckerberg may indeed be hiring people who are less than the best, same for Musk, but the people they hire are making the UX that the rest of us have to put up with.
Given I keep reading claims about heavy agentic coding use at Anthropic, and given what I experience while using ChatGPT, those companies are vibing the UX that the rest of us have to put up with.
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 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.