I don't understand why I keep seeing posts like this, but nobody appears to know that DevContainers exist.
In a Jetbrains IDE, for example, you check a devcontainer.json file into your repository. This file describes how to build a Docker image (or points to a Dockerfile you already have). When you open up a project, the IDE builds the Docker image, automatically installs a language-server backend into it, and launches a remote frontend connected to that container (which may run on the same or a different machine from where the frontend runs).
If you do anything with an AI agent, that thing happens inside the remote container where the project code files are. If you compile anything, or run anything, that happens in the container too. The project directory itself is synced back to your local system but your home directory (and all its credentials) are off-limits to things inside the container.
It's actually easier to do this than to not, since it provides reusable developer tooling that can be shared among all team members, and gives you consistent dependency versions used for local compilation/profiling/debugging/whatever.
DevContainers are supported by a number of IDEs including VSCode.
You should be using them for non-vibe projects. You should DEFINITELY be using them for vibe projects.
I love JetBrains and they’ve gotten better with using devcontainers but they’re still kind of flaky at times. I love using devcontainer too, just wanted to note that.
I found cloning the repo when creating the devcontainer works best in JetBrains for some reason and I hard code the workspace directory so it’s consistent between JetBrains and vscode
Keep in mind that VSCode’s own security story is beyond poor. Even if the container runtime perfectly contains the container, VSCode itself is a hole you could drive a truck through.
I use vim with docker compose all the time: Set up the compose file to bind-mount the repo inside the container, so you can edit files freely outside it, and add a convenience "make shell" that gets you inside the container for running commands (basically just "docker compose exec foo bash").
It sounds like if you make devcontainers point at an existing Dockerfile it should be easy to make these work together, so you and teammates both use the same configuration. I haven't used devcontainers though.
I'd prefer containers, because they are more light weight and I'm not too concerned about kernel exploits or other sandbox escapes. Configuring a container per project brings me right back to something like devcontainer. But I haven't figured out a good way to incorporate that into my vim/tmux workflow.
Hmm, maybe I misunderstood the point of the original comment. I thought the OP was suggesting using containers to isolate resources for development vs personal computing, for which I use a VM. But VMs don’t play nicely with IDEs (hence devcontainers).
It's a variation of sandboxing which is a great idea. Even just using a separate user account on your laptop provides some useful level of isolation (as long as you don't give it sudo privileges). AI tools of course do some sandboxing of their own. It's just that the constant nagging for permissions causes people to negate most of that by giving very broad access outside the sandbox.
The downside for me and the main reason I do use vms less than I did a few months ago is that I need my agentic coding tools to use development tools a lot. And those tools need a lot of resources. And I have those resources on my laptop. Which is a nice mac book pro with plenty of RAM and 16 CPUs. I can run vms on this thing without issues of course. But tools just run a lot faster when I run them outside those VMs. And agentic coding tools run builds all the time. We're talking some really non trivial time savings here. Watching qemu build a thing for 10 minutes that I know should build in 45 seconds is painful. Especially if it happens over and over again.
The trick is doing sandboxing without performance impact. And very soon you'll also want to be able to run local models. I've been toying with the latest qwen and gemma models on my laptop. I haven't gotten around to doing coding with those just yet. But apparently they aren't completely horrible at it. That won't work on most cloud based vms. Unless you get a really big and expensive one. You could actually make that work if you only use them for a few minutes.
I was using Docker containers for sandboxing but it was annoying at times, not so much for the performance hit (which wasn’t noticeable running in OrbStack) but various little papercuts like no shared clipboard, node_modules pulling in Linux binaries or macOS binaries depending on whether I ran npm install from inside the sandbox or my own shell, etc.
With agent-safehouse, I get the isolation I want (more customizable than with Docker) without needing a VM or container.
I remember someone on HN once saying they treat LLM agents like human coworkers, security-wise, and that stuck with me.
You don't give your GH keys, email credentials and ssh keys to a coworker. They have their own accounts with scoped permissions. Need them to read an email? Forward it. Need them to work on a repo? Add them as a contributor and enforce the same branch policies you would for any human.
There are still risks, but they're similar to delegating work to humans, so it's up to you how much access and trust to give.
I think the issue is that people see them as agents of themselves with the authority to act on their behalf, much like a personal assistant, rather than a coworker.
I would guess OpenAI Codex and Claude Code are well into the millions subscriber range at this point. I would venture to guess the majority of them run in yolo mode. I have only seen a few horror stories on reddit. The same way any time you drive a car you can crash and die (many times through no fault of your own).
All that said, no way in hell I’m giving either access to production databases or environments.
I have heard of more than a few horror stories including filesystems lost and force pushes done.
These tools have only been in use for a short time and the current harnesses/system prompts are quite limited. Claude code is mostly limited to your codebase where you have version control. Excel is different.
I foresee that once people hand over more power to full agents there will be some nasty surprises. Im sure there will eventually be demand for some kind of limits
Yeah, I was thinking about simonw's lethal trifecta[0] and how to solve it and my conclusion was "you cannot", i.e. you just accept a certain level of risks for the rewards it offers.
The "agent never sees keys" approach prevents key exfiltration, but it doesn't prevent agent from nuking what it has access to, nor prevent data exfiltration.
The best advice I heard to protect against prompt injection was "just use Opus" ( ... which was great advice before they lobotomized it ;)
But even without injection, most of the horror stories are from random error, or the AI trying to be helpful (e.g. stealing your keys or working around security restrictions, because they trained or to really want to complete a task.[1])
Codex 5.4 medium couldn’t figure out how to run tests in my staging Cloudflare so it went ahead and ran those tests against prod. Mission accomplished.
The fact that Claude can and does access files outside the PWD while asking for sudo to do things constantly seems to be a recipe for Anthropic scanning your system without your knowledge and saving that for 5 years if you decided to 'help improve Claude'.
No, 'safety oriented' lab has a clause like that which can't be revoked historically. Anthropic, like the majority of 'don't be evil' firms is apart of the great masquerade.
Some weeks ago I opened Zeditor, it asks me if I want AI, I say yes, a sidebar opens I ask said LLM: What can you see? It does some `ls`'s, it sees my .ssh folder and priv keys. I turned it off. Now I run Claude code in a container with just pwd mounted to it.
The whole experience was a bit jarring. When it knows I use nix, the the thing can easily `nix-shell -p nmap` its way into learning a lot more about my entire network than I am comfortable with. I think I'll edit the Containerfile further to also make Claude Code a user that can't install anything.
It's really like some "agent" (yeah I know, but I mean really an external person) takes control of your computer, with the same privileges as you. Idk why I had to see this happen in front of my eyes to fully realize this.
Of course every computer program has these rights, and you have to trust any of these devs...
> The whole experience was a bit jarring. When it knows I use nix, the the thing can easily `nix-shell -p nmap` its way into learning a lot more about my entire network than I am comfortable with. I think I'll edit the Containerfile further to also make Claude Code a user that can't install anything.
Note that putting it in container changes jack shit, if it still has network access, it can scan your network anyway, and it needs access to install language deps and such to "do its work"
> Don't just rawdog a coding agent because a perfectly viable solution (containers) takes an hour or two of work to set up.
Setting up a separate unprivileged Linux user account takes all of like a minute. Assuming that the $HOME for your daily-driver account isn't world-readable, [0] that gets you the majority of the isolation that containerization provides and doesn't expose you to any bugs in the containerization management daemon (or the containerization code, itself) that may still be present even after all these years.
These things are usually TUIs or CLIs, so you don't need to bother with giving them xauth access or whatever the Wayland equivalents for that are.
[0] If it is, you might consider fixing that immediately.
> Note that putting it in container changes jack shit, if it still has network access, it can scan your network anyway...
That's why VLANs are nice, as is requiring your container system (or VM or whatever) to attach its vNICs to a VLAN-tagged bridge on the host rather than the untagged interface that your trusted software uses. If the only thing that the container can hit on your LAN is your router, and your router refuses to forward traffic from that untrusted VLAN to anywhere other than the internet, then that cuts off another avenue for intelligence gathering.
That all assumes that you can't exploit the container daemon to get root, of course.
That's what happens with propietary software. No sane person -for work if your dumb $BOSS makes in mandatory- should be using that outside of a Guix/Nix env with really constrained settings.
At home I have no propietary software at all modulo some original GBC ROMs I dumped to play with emulators, but that is not my 'daily computing' usage but an act of nostalgia.
I use a separate user account per project on my local machine (not in sudoers), which I ssh to, and also runs tmux. If I need claude code in windows, then I run a VM. The performance and (in)convenience cost of this to me is minimal. I started working this way in order to limit the "blast radius" when claude went on a dependency binge within a project.
> The actual development happens on a rented server
Why not Hyper-V or libvirt/KVM? VM escapes aren't a thing in real life (or VMs from hyperscalers wouldn't exist), so why deal with additional cost, latency, and third-party trust when you could just run it yourself?
OrcaBot does this with the VM but whereas the author mentions the risk of GitHub keys being leaked, OrcaBot uses a key broker to ensure the LLM doesn’t have access to any keys. It even works on the API keys to the LLMs themselves.
https://orcabot.com/blog#breaking-the-lethal-trifecta
This works well for vibecoding on a codebase in isolation, which to be fair is what the author is addressing. I don’t think it solves the problems at the current frontier of agent use though, where you expose internal infrastructure via tools to make the agent maximally productive. How to do this safely is still unsolved
Limit access to whatever their project requires. The difference is that human interns have some common sense and won't suddenly be hijacked by a hidden message they stumble upon while searching the web, instructing them to exfiltrate a bunch of proprietary data. It is surprisingly easy to get an agent to do that though
bsd is super easy for this kind of setup tbh. Sylve or Bastille is amazing for it. 1 liner jails setups etc. its real quick and efficient. depending on flavor u can also use pledge/unveil or capsicum or whatever to lock things down even more.
I've been doing something similar by letting Claude run in a Virtualbox VM. It's easy to use, no issues with observability, and the attack & damage surface is far less of an issue.
Generally a good idea, but I'm not sure why you should even want to fork a git repo when a local clone should be sufficient. But this is probably a terminology mixup from the way github presents forks and clones.
I believe the author's idea is to do dev work from a Github account that only has access to the fork, but not to the main repo. Then, as a contributor, you'd open PRs from your fork to the main repo. I think this would only work if your Github account doesn't have write access to the main repo, though. I know you can use 'deployment keys' to give read-access to a single repo using an SSH key, but not sure if you can otherwise restrict access to a single repo with write access. Essentially, though, you'd want to find a way to give the remote host the most limited possible privileges to your Github account.
You could also just set the development machine up as a remote on the repo on your local host and then pull, diff, and merge locally. Then the llm agent doesn’t have access to any github account at all.
I use an overlay copy of my workdir, then the sandboxed LLM doesn't get any of my secrets, can do its own commits, and I pull the ones back that I want.
Oh, a separate GitHub account that has its own forks of the repos the agent is working on. Yeah, that's probably the most secure, isolated, and safest. The merge to the canonical repo then needs to go through a human, or at least separately controlled, process via a GitHub pull request.
> if you accidentally run the wrong command in sudo
I'm not seeing your point. Are you saying that I shouldn't use sudo because I might accidentally "run the wrong command"?
I know all the commands that I run and what they do.
> your kernel is not isolate
Am I more afraid of an npm package exploiting a zero day kernel vulnerability on my mac? Or just stealing my AWS keys and installing a crypto miner? Sudo suits my threat model just fine.
My m3 MacBook pro is a million times more powerful dev machine than a cheap $5 vps. Why would I waste my time with that.
This is what dev.exe is great for, and it comes with Pi and its own coding agent Shelley preloaded. Also it’s incredibly fast and you can easily access the VMs from your phone.
IM new to Claude code but doesnt auth require a gui browser to authenticate the Claude session first time login?? Do you have to setup a desktop environment just for that?
claude-cli executes whatever is in the BROWSER env variable to open your browser at a current URL, so I pointed it at a simple shell script that writes the URL to a named pipe which is mounted into the container. The sandbox tool outside of the container is reading from that named pipe. When it receives a URL to open, it pops up a confirmation dialog with info about the URL. If you accept, it opens it in your host browser.
The second step is, the callback URL after you sign in on the claude website wants to connect back to a port on localhost to complete the sign in. If the sandbox is being run with host networking mode, this just works fine as claude cli has already opened that port so it's listening on the host network. However if it is not running in host networking mode, the sandbox tool figures out what port it need to listen on from looking at the URL, listens to it, and when it is hit, it just podman exec's curl inside the container to complete the callback.
You can run all the major CLI tools without a browser.
When they try to open a browser, they also print the URL to the console. Open that in your browser and go through an authentication flow; it'll end forwarding you to a localhost URL like http://127.0.0.1:8080/authorization-code/callback?code=XXXX&... which will fail.
Copy that callback URL, connect to your VM/docker container, and curl it.
The curl stage requires the agent make a call to auth.whatever-vendor.com so if it fails at this stage, check your VM/container network settings. And make sure you quoted the curl right so the & wasn't misinterpreted.
It'll then save a file at ~/.codex/auth.json or ~/.claude.json or similar, so you won't need to log in again. The secret in this file will periodically rotate, so you need to mount it read-write not read-only.
You can copy your claude credentials into the VM and run off that. Just beware that the subscription credentials file expires every half hour and then the agent tries to refresh which is annoying (especially if you have multiple sandboxed agents), so the better way is to get a long-running subscription API key (no extra cost for that) and just pass it in.
If the Claude (or similar) can't open a browser on a headless server, they typically print a URL you can copy to your browser on your local system-with-GUI. From there you authenticate and get back some kind of token, which you copy and paste back into your remote SSH session.
Ten more years and our tricks become the ancient practices and rituals of the olden hack0rs; stuff like apt update and apt upgrade on a fresh server. Some of the most ancient even use apt-get, while the really old ones will scold you for using Ubuntu
Also, "ssh -A" is your friend. Keep your ssh key on your yubikey where you control it. Let Claude play on it's own VM and in its own clone of your repo. Only when you choose to add the -A, do you temporarily, for that one ssh connection, have the possibility to push Claude's work to your repo, where you can review it.
Treat it as a colleague, making PRs that you review.
I’m building a claw / vibe coding platform that’s business safe at https://housecat.com and am also finding all the old Unix tricks working as well as ever…
- user and home directory for data
- crontab for scheduled jobs
- cgi for serving user space apps
- rsync for backups
We even rediscovered email patches but with agent to agent help making and applying them.
It’s simpler for us to operate and the agent to figure out.
# Create a new sandbox copying . as workdir (default container, but you can choose vm)
yoloai new mybugfix . --isolation vm
# attach to it (it has tmux already)
yoloai attach mybugfix
# Chat with the bot inside...
# Happy with its work? Diff it to be sure
yoloai diff mybugfix
# Happy with the changes? Apply them to your workdir
yoloai apply mybugfix
# All done? Destroy the sandbox
yoloai destroy mybugfix
The agent stays isolated at all times. No access to your secrets (except what you want), no access to your workdir until you apply. You can also easily restrict network access.
This does the same thing as in the blog post, except that there are a LOT of gotchas and minutiae and some yak shaving involved if you want to keep doing it manually.
I've gone through the whole path the author has, and finally had to admit that it's too much fiddling around to do it manually. Easier to just have a cmdline tool that does it for you. That's why I built it in the first place.
It actually runs git (with hooks disabled) to generate the diff. It happens on the host when using copy mode, and inside the sandbox when using overlay mode.
The above example doesn't specify workdir mounting mode, so it would be copy, not overlay.
I don't understand why I keep seeing posts like this, but nobody appears to know that DevContainers exist.
In a Jetbrains IDE, for example, you check a devcontainer.json file into your repository. This file describes how to build a Docker image (or points to a Dockerfile you already have). When you open up a project, the IDE builds the Docker image, automatically installs a language-server backend into it, and launches a remote frontend connected to that container (which may run on the same or a different machine from where the frontend runs).
If you do anything with an AI agent, that thing happens inside the remote container where the project code files are. If you compile anything, or run anything, that happens in the container too. The project directory itself is synced back to your local system but your home directory (and all its credentials) are off-limits to things inside the container.
It's actually easier to do this than to not, since it provides reusable developer tooling that can be shared among all team members, and gives you consistent dependency versions used for local compilation/profiling/debugging/whatever.
DevContainers are supported by a number of IDEs including VSCode.
You should be using them for non-vibe projects. You should DEFINITELY be using them for vibe projects.
Yeah, it's easy to vibecode and review a docker sandbox, too. If you run containers with
it's pretty tight. That's how I use coding agents, FWIW.I love JetBrains and they’ve gotten better with using devcontainers but they’re still kind of flaky at times. I love using devcontainer too, just wanted to note that.
I found cloning the repo when creating the devcontainer works best in JetBrains for some reason and I hard code the workspace directory so it’s consistent between JetBrains and vscode
Keep in mind that VSCode’s own security story is beyond poor. Even if the container runtime perfectly contains the container, VSCode itself is a hole you could drive a truck through.
The main Claude Code GitHub repo even has a Devcontainer config:
https://github.com/anthropics/claude-code
It's a great starting point, and can be customized as needed. With the devcontainer CLI, you can even use it from a terminal, no GUI/IDE required.
Is there a guide on getting it working with a devcontainer on the command line?
Yes, I summarized the process in another comment recently:
https://news.ycombinator.com/item?id=47546014
That should be enough to get you going. It can be customized to your heart's content.
Has anyone figured out a good way to use (neo)vim with devcontainers?
I use vim with docker compose all the time: Set up the compose file to bind-mount the repo inside the container, so you can edit files freely outside it, and add a convenience "make shell" that gets you inside the container for running commands (basically just "docker compose exec foo bash").
It sounds like if you make devcontainers point at an existing Dockerfile it should be easy to make these work together, so you and teammates both use the same configuration. I haven't used devcontainers though.
I personally just use Vim directly in a dedicated development VM that I SSH into. I can always spin up a new one if something goes astray
I'd prefer containers, because they are more light weight and I'm not too concerned about kernel exploits or other sandbox escapes. Configuring a container per project brings me right back to something like devcontainer. But I haven't figured out a good way to incorporate that into my vim/tmux workflow.
Hmm, maybe I misunderstood the point of the original comment. I thought the OP was suggesting using containers to isolate resources for development vs personal computing, for which I use a VM. But VMs don’t play nicely with IDEs (hence devcontainers).
haven't tried it but amitds1997/remote-nvim.nvim
I need something like that though that's one of the thing that pains me the most while trying to use vim/nvim for dev
I used to use sealtbelts for sandbox, i found it consumes way more tokens when sandboxed.
Now, i run YOLO and haven't had any issue and my subscription lasts much longer with less token consumption!
How/why did it consume more tokens?
Well, thing is I ask it doesn't things where sandbox fails.
And then it has to bypass sandbox to run those command with elevated permission.
This double tripe boosts token usage.
I don't think average developer workflow can be really limited to a workspace. You'll need commands which touch your system or require more privilege
It's a variation of sandboxing which is a great idea. Even just using a separate user account on your laptop provides some useful level of isolation (as long as you don't give it sudo privileges). AI tools of course do some sandboxing of their own. It's just that the constant nagging for permissions causes people to negate most of that by giving very broad access outside the sandbox.
The downside for me and the main reason I do use vms less than I did a few months ago is that I need my agentic coding tools to use development tools a lot. And those tools need a lot of resources. And I have those resources on my laptop. Which is a nice mac book pro with plenty of RAM and 16 CPUs. I can run vms on this thing without issues of course. But tools just run a lot faster when I run them outside those VMs. And agentic coding tools run builds all the time. We're talking some really non trivial time savings here. Watching qemu build a thing for 10 minutes that I know should build in 45 seconds is painful. Especially if it happens over and over again.
The trick is doing sandboxing without performance impact. And very soon you'll also want to be able to run local models. I've been toying with the latest qwen and gemma models on my laptop. I haven't gotten around to doing coding with those just yet. But apparently they aren't completely horrible at it. That won't work on most cloud based vms. Unless you get a really big and expensive one. You could actually make that work if you only use them for a few minutes.
agent-safehouse (https://agent-safehouse.dev) was my answer to this.
I was using Docker containers for sandboxing but it was annoying at times, not so much for the performance hit (which wasn’t noticeable running in OrbStack) but various little papercuts like no shared clipboard, node_modules pulling in Linux binaries or macOS binaries depending on whether I ran npm install from inside the sandbox or my own shell, etc.
With agent-safehouse, I get the isolation I want (more customizable than with Docker) without needing a VM or container.
You can run inside of a tart vm which gives you a virtual mac. It's pretty speedy once it's up and running.
I remember someone on HN once saying they treat LLM agents like human coworkers, security-wise, and that stuck with me.
You don't give your GH keys, email credentials and ssh keys to a coworker. They have their own accounts with scoped permissions. Need them to read an email? Forward it. Need them to work on a repo? Add them as a contributor and enforce the same branch policies you would for any human.
There are still risks, but they're similar to delegating work to humans, so it's up to you how much access and trust to give.
I think the issue is that people see them as agents of themselves with the authority to act on their behalf, much like a personal assistant, rather than a coworker.
I would guess OpenAI Codex and Claude Code are well into the millions subscriber range at this point. I would venture to guess the majority of them run in yolo mode. I have only seen a few horror stories on reddit. The same way any time you drive a car you can crash and die (many times through no fault of your own).
All that said, no way in hell I’m giving either access to production databases or environments.
I have heard of more than a few horror stories including filesystems lost and force pushes done.
These tools have only been in use for a short time and the current harnesses/system prompts are quite limited. Claude code is mostly limited to your codebase where you have version control. Excel is different.
I foresee that once people hand over more power to full agents there will be some nasty surprises. Im sure there will eventually be demand for some kind of limits
Yeah, I was thinking about simonw's lethal trifecta[0] and how to solve it and my conclusion was "you cannot", i.e. you just accept a certain level of risks for the rewards it offers.
The "agent never sees keys" approach prevents key exfiltration, but it doesn't prevent agent from nuking what it has access to, nor prevent data exfiltration.
The best advice I heard to protect against prompt injection was "just use Opus" ( ... which was great advice before they lobotomized it ;)
But even without injection, most of the horror stories are from random error, or the AI trying to be helpful (e.g. stealing your keys or working around security restrictions, because they trained or to really want to complete a task.[1])
tl;dr yolo
[0] https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
[1] https://www.reddit.com/r/ClaudeAI/comments/1r186gl/my_agent_...
Codex 5.4 medium couldn’t figure out how to run tests in my staging Cloudflare so it went ahead and ran those tests against prod. Mission accomplished.
Yes, agents.md yells not to mess with prod.
> Yes, agents.md yells not to mess with prod.
Probably what nudged it to run on prod in the first place
The fact that Claude can and does access files outside the PWD while asking for sudo to do things constantly seems to be a recipe for Anthropic scanning your system without your knowledge and saving that for 5 years if you decided to 'help improve Claude'.
No, 'safety oriented' lab has a clause like that which can't be revoked historically. Anthropic, like the majority of 'don't be evil' firms is apart of the great masquerade.
Some weeks ago I opened Zeditor, it asks me if I want AI, I say yes, a sidebar opens I ask said LLM: What can you see? It does some `ls`'s, it sees my .ssh folder and priv keys. I turned it off. Now I run Claude code in a container with just pwd mounted to it.
The whole experience was a bit jarring. When it knows I use nix, the the thing can easily `nix-shell -p nmap` its way into learning a lot more about my entire network than I am comfortable with. I think I'll edit the Containerfile further to also make Claude Code a user that can't install anything.
It's really like some "agent" (yeah I know, but I mean really an external person) takes control of your computer, with the same privileges as you. Idk why I had to see this happen in front of my eyes to fully realize this.
Of course every computer program has these rights, and you have to trust any of these devs...
> The whole experience was a bit jarring. When it knows I use nix, the the thing can easily `nix-shell -p nmap` its way into learning a lot more about my entire network than I am comfortable with. I think I'll edit the Containerfile further to also make Claude Code a user that can't install anything.
Note that putting it in container changes jack shit, if it still has network access, it can scan your network anyway, and it needs access to install language deps and such to "do its work"
It's a security nightmare.
Every goddamn time with this type of dogshit advice.
Perfect is the enemy of good.
Don't just rawdog a coding agent because a perfectly viable solution (containers) takes an hour or two of work to set up.
There's a world of difference between "it can scan your network" and "I just uploaded my private SSH keys to the cloud".
> Don't just rawdog a coding agent because a perfectly viable solution (containers) takes an hour or two of work to set up.
Setting up a separate unprivileged Linux user account takes all of like a minute. Assuming that the $HOME for your daily-driver account isn't world-readable, [0] that gets you the majority of the isolation that containerization provides and doesn't expose you to any bugs in the containerization management daemon (or the containerization code, itself) that may still be present even after all these years.
These things are usually TUIs or CLIs, so you don't need to bother with giving them xauth access or whatever the Wayland equivalents for that are.
[0] If it is, you might consider fixing that immediately.
See, I like this. "Create a new user account" is much better advice than "don't use a container".
My problem with the latter advice is that I know for a fact that people will read it, then continue to use absolutely no protection whasoever.
I have also wanted to use a simple file permission system, but I started with a container and I can't be troubled to switch yet.
> Note that putting it in container changes jack shit, if it still has network access, it can scan your network anyway...
That's why VLANs are nice, as is requiring your container system (or VM or whatever) to attach its vNICs to a VLAN-tagged bridge on the host rather than the untagged interface that your trusted software uses. If the only thing that the container can hit on your LAN is your router, and your router refuses to forward traffic from that untrusted VLAN to anywhere other than the internet, then that cuts off another avenue for intelligence gathering.
That all assumes that you can't exploit the container daemon to get root, of course.
That's what happens with propietary software. No sane person -for work if your dumb $BOSS makes in mandatory- should be using that outside of a Guix/Nix env with really constrained settings.
At home I have no propietary software at all modulo some original GBC ROMs I dumped to play with emulators, but that is not my 'daily computing' usage but an act of nostalgia.
Exactly my worry, so I've bubblewrapped it on my computer. https://kaveh.page/blog/claude-code-sandbox
Great balance of simplicity and functionality. I'll be adapting this for VSCode+Cline. Thanks for sharing.
It does but AFAIK it always asks me if I want to allow it unless it has it saved that permission was already given.
I use a separate user account per project on my local machine (not in sudoers), which I ssh to, and also runs tmux. If I need claude code in windows, then I run a VM. The performance and (in)convenience cost of this to me is minimal. I started working this way in order to limit the "blast radius" when claude went on a dependency binge within a project.
Good checklist, but
> The actual development happens on a rented server
Why not Hyper-V or libvirt/KVM? VM escapes aren't a thing in real life (or VMs from hyperscalers wouldn't exist), so why deal with additional cost, latency, and third-party trust when you could just run it yourself?
OrcaBot does this with the VM but whereas the author mentions the risk of GitHub keys being leaked, OrcaBot uses a key broker to ensure the LLM doesn’t have access to any keys. It even works on the API keys to the LLMs themselves. https://orcabot.com/blog#breaking-the-lethal-trifecta
- I still have no idea what people are running for more than 5 mins with agents
This works well for vibecoding on a codebase in isolation, which to be fair is what the author is addressing. I don’t think it solves the problems at the current frontier of agent use though, where you expose internal infrastructure via tools to make the agent maximally productive. How to do this safely is still unsolved
I mean this question unironically: how do you do it with interns?
Limit access to whatever their project requires. The difference is that human interns have some common sense and won't suddenly be hijacked by a hidden message they stumble upon while searching the web, instructing them to exfiltrate a bunch of proprietary data. It is surprisingly easy to get an agent to do that though
bsd is super easy for this kind of setup tbh. Sylve or Bastille is amazing for it. 1 liner jails setups etc. its real quick and efficient. depending on flavor u can also use pledge/unveil or capsicum or whatever to lock things down even more.
> I SSH into that server with key-forwarding
Almost back to point A then. If the server is compromised in some way, they can use (not copy) OP's keys and use them to clone repos/inject code/etc..
I've been doing something similar by letting Claude run in a Virtualbox VM. It's easy to use, no issues with observability, and the attack & damage surface is far less of an issue.
Generally a good idea, but I'm not sure why you should even want to fork a git repo when a local clone should be sufficient. But this is probably a terminology mixup from the way github presents forks and clones.
I believe the author's idea is to do dev work from a Github account that only has access to the fork, but not to the main repo. Then, as a contributor, you'd open PRs from your fork to the main repo. I think this would only work if your Github account doesn't have write access to the main repo, though. I know you can use 'deployment keys' to give read-access to a single repo using an SSH key, but not sure if you can otherwise restrict access to a single repo with write access. Essentially, though, you'd want to find a way to give the remote host the most limited possible privileges to your Github account.
You could also just set the development machine up as a remote on the repo on your local host and then pull, diff, and merge locally. Then the llm agent doesn’t have access to any github account at all.
I use an overlay copy of my workdir, then the sandboxed LLM doesn't get any of my secrets, can do its own commits, and I pull the ones back that I want.
Oh, a separate GitHub account that has its own forks of the repos the agent is working on. Yeah, that's probably the most secure, isolated, and safest. The merge to the canonical repo then needs to go through a human, or at least separately controlled, process via a GitHub pull request.
Maybe this is doable with scoped API keys instead of SSH keys?
On a GitHub project, agents must just be considered untrusted external contributors.
They mention that as a mechanism for protecting the SSH keys for the repo.
Essentially using a repo that doesn’t matter with the coding agent and then creating a cross-repo PR to the real repo.
People seem to come up with all manner of complicated setups with virtual machines or docker or whatever.
All you need is a separate limited user account on your computer. Multi-user Unix-y systems were designed for this kind of thing for decades.
My entire development environment is literally just "sudo".
your kernel is not isolate and if you accidentally run the wrong command in sudo you will nuke your computer lol
or just have a linux vps and ssh in for $5 a month
> if you accidentally run the wrong command in sudo
I'm not seeing your point. Are you saying that I shouldn't use sudo because I might accidentally "run the wrong command"?
I know all the commands that I run and what they do.
> your kernel is not isolate
Am I more afraid of an npm package exploiting a zero day kernel vulnerability on my mac? Or just stealing my AWS keys and installing a crypto miner? Sudo suits my threat model just fine.
My m3 MacBook pro is a million times more powerful dev machine than a cheap $5 vps. Why would I waste my time with that.
yes you right, i assume you using claude code which can in fact accidentally run the wrong command
https://www.reddit.com/r/ClaudeAI/comments/1n1moqy/how_did_c...
https://www.reddit.com/r/ClaudeCode/comments/1sa3fx8/claude_...
https://old.reddit.com/r/ClaudeAI/comments/1jfidvb/claude_tr...
My Claude runs as a limited user account, which I invoke using sudo.
Claude can run whatever commands it wants and the only harm it can do is nuke its own home directory. That's the whole point.
They weren't getting that sudo was just your mechanism for changing user.
The advantage of VMs is that you can nuke them and be done with it if you need to.
I use my personal laptop for $WORK and everything work related is done via the VM.
I can do that too by just rm-rf the agents home directory
I've been successful with getting incus running with this for sandboxing the opencode session. I plan on writing a blog post on it.
This might interest you (disclaimer my project. Well mostly Opus')
https://github.com/jgbrwn/vibebin
This is what dev.exe is great for, and it comes with Pi and its own coding agent Shelley preloaded. Also it’s incredibly fast and you can easily access the VMs from your phone.
IM new to Claude code but doesnt auth require a gui browser to authenticate the Claude session first time login?? Do you have to setup a desktop environment just for that?
https://gitlab.com/grepular/claude-sandbox runs claude in a podman container. The way it deals with this is:
claude-cli executes whatever is in the BROWSER env variable to open your browser at a current URL, so I pointed it at a simple shell script that writes the URL to a named pipe which is mounted into the container. The sandbox tool outside of the container is reading from that named pipe. When it receives a URL to open, it pops up a confirmation dialog with info about the URL. If you accept, it opens it in your host browser.
The second step is, the callback URL after you sign in on the claude website wants to connect back to a port on localhost to complete the sign in. If the sandbox is being run with host networking mode, this just works fine as claude cli has already opened that port so it's listening on the host network. However if it is not running in host networking mode, the sandbox tool figures out what port it need to listen on from looking at the URL, listens to it, and when it is hit, it just podman exec's curl inside the container to complete the callback.
You can run all the major CLI tools without a browser.
When they try to open a browser, they also print the URL to the console. Open that in your browser and go through an authentication flow; it'll end forwarding you to a localhost URL like http://127.0.0.1:8080/authorization-code/callback?code=XXXX&... which will fail.
Copy that callback URL, connect to your VM/docker container, and curl it.
The curl stage requires the agent make a call to auth.whatever-vendor.com so if it fails at this stage, check your VM/container network settings. And make sure you quoted the curl right so the & wasn't misinterpreted.
It'll then save a file at ~/.codex/auth.json or ~/.claude.json or similar, so you won't need to log in again. The secret in this file will periodically rotate, so you need to mount it read-write not read-only.
You can copy your claude credentials into the VM and run off that. Just beware that the subscription credentials file expires every half hour and then the agent tries to refresh which is annoying (especially if you have multiple sandboxed agents), so the better way is to get a long-running subscription API key (no extra cost for that) and just pass it in.
If the Claude (or similar) can't open a browser on a headless server, they typically print a URL you can copy to your browser on your local system-with-GUI. From there you authenticate and get back some kind of token, which you copy and paste back into your remote SSH session.
the old hacker trick of using ssh
Ten more years and our tricks become the ancient practices and rituals of the olden hack0rs; stuff like apt update and apt upgrade on a fresh server. Some of the most ancient even use apt-get, while the really old ones will scold you for using Ubuntu
Hey! I resemble that comment :-P (I still tend to use apt-get out of habit...)
My other Mac mini is the cloud ;)
Why not just not vibecode? Safer methods of injecting recreational narcotics, such madness.
Also, "ssh -A" is your friend. Keep your ssh key on your yubikey where you control it. Let Claude play on it's own VM and in its own clone of your repo. Only when you choose to add the -A, do you temporarily, for that one ssh connection, have the possibility to push Claude's work to your repo, where you can review it.
Treat it as a colleague, making PRs that you review.
...and proxy your llm traffic with your own per session tokens – if it leaks, it doesn't matter, not a real token.
Apparently using SSH is some leet hacker thing according to this OP. Lmao...
"Vibecoding?"
Gotta love how someone downvoted this.
I’m building a claw / vibe coding platform that’s business safe at https://housecat.com and am also finding all the old Unix tricks working as well as ever…
- user and home directory for data
- crontab for scheduled jobs
- cgi for serving user space apps
- rsync for backups
We even rediscovered email patches but with agent to agent help making and applying them.
It’s simpler for us to operate and the agent to figure out.
This is what yoloAI does. Automatically.
The agent stays isolated at all times. No access to your secrets (except what you want), no access to your workdir until you apply. You can also easily restrict network access.https://github.com/kstenerud/yoloai
Spammy ai-generated self promotion.
In what way?
This does the same thing as in the blog post, except that there are a LOT of gotchas and minutiae and some yak shaving involved if you want to keep doing it manually.
I've gone through the whole path the author has, and finally had to admit that it's too much fiddling around to do it manually. Easier to just have a cmdline tool that does it for you. That's why I built it in the first place.
The part that worries me here is the diff. Does it happen in the host or in the guest? What code gets run when you run `yoloai diff`?
It actually runs git (with hooks disabled) to generate the diff. It happens on the host when using copy mode, and inside the sandbox when using overlay mode.
The above example doesn't specify workdir mounting mode, so it would be copy, not overlay.
If it runs inside the sandbox and the guest is compromised, can't the guest just lie?
Absolutely. That's why overlay is not the default.
That's... uh, an interesting approach to security.
What is? Defaulting to the most secure method?