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.
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 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 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.
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.
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.
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
I've been using unix systems in one way or another for the last 30+ years. I only last week figured out I could use authorized_keys with dedicated commands per key as a way to transparently ssh directly into a container on a remote host.
That ability to transparently start a container and connect it to the SSH pipr is useful for isolation methods for coding agents involving containers and I imagine it would work equally well for things like Firecracker VMs. It's made my experiment working with an "immutable OS" (Universal Blue based) much more ergonomic. Also, it's the only way I've found to let Zed run remotely inside a container without having the container run a ssh server.
> 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?
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.
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'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.
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.
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?
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.
Slightly safer vibecoding by adopting old hacker habits
(addxorrol.blogspot.com)
94 comments
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 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
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.
https://news.ycombinator.com/item?id=47546014
That should be enough to get you going. It can be customized to your heart's content.
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 need something like that though that's one of the thing that pains me the most while trying to use vim/nvim for dev
Now, i run YOLO and haven't had any issue and my subscription lasts much longer with less token consumption!
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.
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.
All that said, no way in hell I’m giving either access to production databases or environments.
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.
That ability to transparently start a container and connect it to the SSH pipr is useful for isolation methods for coding agents involving containers and I imagine it would work equally well for things like Firecracker VMs. It's made my experiment working with an "immutable OS" (Universal Blue based) much more ergonomic. Also, it's the only way I've found to let Zed run remotely inside a container without having the container run a ssh server.
> 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?
> 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..
Treat it as a colleague, making PRs that you review.
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".
Gotta love how someone downvoted this.
- 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.
https://github.com/kstenerud/yoloai