If you are a VSCode hater (like me), you can achieve the same thing using the open-source, Microsoft-built, official devcontainer CLI [0], which is exactly what VSCode uses under the hood. You don't get automatic port forwarding with this tool, which includes SSH Agent forwarding, so you'll likely want to pair this with installing SSH into your devcontainers, or using some other tool that does the job. I built a tool [1] to do the port forwarding part, which I'd like to be more magic like VSCode's but haven't put the effort into doing, since it works for my purposes.
Using these, I can SSH into my devserver, use the devcontainer CLI to open a tmux session with iTerm2 Tmux integration, and it feels just like a local window. Combine that with Neovide and remote Neovim over the same channel, and I have a native-feeling dev environment running on a remote devcontainer in a nearby data center.
I ssh into my server, then use the devcontainer cli tool to open a shell in the dev container. Found that easier than installing ssh in every container, especially when there's lots of them. I made a simple command line tool for helping the process, so I don't have to type out any long commands. If I run it it will list the running dev containers and I give them each a number to I don't have to use the full ID.
I like the CLI for commands, but would rather work with an agent chat interface for vibing, which unfortunately I’m becoming increasingly reliant on, even though it’s gotten me into trouble with larger projects.
I have many environments locally, some dependent on others, and some require local databases. I use containers in production, but not always locally.
It’s almost a hellscape situation for trying to setup a fully isolated dev environment. I might be able have have some future generation of Claude convert my existing dev setup to something isolated with k8s. But, I don’t have the power to run such an environment locally, with all of the apps and services. I’d need to set my dev environments up in the cloud, but I don’t have enough money to pay for that, and it wouldn’t even work in some circumstances, because some things must run locally.
So, instead I run Cursor AI with various MCP servers, I approve tool calls, I don’t have things isolated, and I know this will eventually bite me.
I have enjoyed running Claude Code in a container. The biggest advantage for me isn't security though, it's how easy it becomes to spin off agents to work in the background.
I use a simple script that copies my working directory into a container, prompts Claude Code, and then either saves a planning document locally, or opens a pull request in GitHub for me to review.
I quite like this because it makes starting agents when I have ideas really frictionless, and then I can easily discard the results and try again if it went off the rails. The Max plan makes me not worry about the cost of this whole process as well.
I also set up containers initially out of caution, but honestly, I've never seen Claude Code do anything that git couldn't easily reverse, so I'm not that worried about that any more.
I have, but I just found that a bit tedious to manage manually. Maybe another version of this script would just be to automatically create a worktree, run a prompt in that, and then have the script manage the results, and clean up the worktree at the end.
They can, but I find it harder to review if you are trying to get Claude Code to do anything non-trivial. I've seen some people make multiple git worktrees so they can have two instances of Claude Code working independently, but I found that to be tedious to manage.
I'm afraid it is not that shareable as it contains a lot of dependency management and setup that is specific to my setup and projects. But it's not too complicated. You could probably re-create your own version fairly quickly.
It's just a Dockerfile that installs dependencies, an entrypoint that invokes claude, and some wrapper scripts that handle creating the container, passing through the prompt, and managing the results (e.g., output markdown to a directory, or open a PR). For input/output from the container I mount directories within the Docker container to local directories under ~/.call_claude/. I create a directory under there, clone the source code to it, output the prompt to a text file, and then grab results from that directory after Claude Code has finished running.
I have actually been working on something similar but instead of Docker, I am using Apple’s builtin container[1] support to run shell commands and code with real OS-level isolation. It’s fast (spawns in milliseconds) and integrates nicely with things like Claude Code and the Gemini CLI. I open sourced it as CodeRunner[2]. Would love to hear what people think or chat about how it compares.
This is my approach but it wasn’t all smooth. And Docker wants you to install their Desktop software which is crap. I am not touching that thing. Yes, devcontainer extension is a thing but it’s a simple tool. We need something robust OOTB.
Yes please, more containers-first thinking for all things AI. The fact that this has been largely absent from most discussions and demos regarding agents and vibe-coding seems like a big red flag to me. I mean if we're going to YOLO the code, perhaps we should at least pay some attention to the dev / test harness?
It's worth thinking about reproducibility even if you're not concerned about security. We would not have to argue so much about the effectiveness of something like vibe-coding if everyone could simply share process/tooling without tons of custom setup. And even if you're not worried about filesystem sandboxing and leaking secrets like ssh keys, even if versioning with git is enough of an undo button for you.. who wants to clutter their whole system with a ton of new language stacks and/or weird dependencies for every small experiment? Most experiments with the new hotness are going to fail, so we should expect to do a lot..
Containers bring their own set of problems, there are some examples brought up in this thread, mainly around communication with the host OS.
I‘d argue the reproducible parts of vibe coding (agentic engineering) setups are just text files. Many people use a mix of web apps (AI studio), Mac apps (Wispr Flow), and other UI tools (repo prompt) in their workflow which can’t be put in a container anyway - well, reasonably at least.
If you want security, containers won’t get you that far. You’ll need to use a VM.
But if you give Claude Code access to your GitHub repo, what else is there worth protecting, that’s not protected by keychain & sudo?
All development is text files, that is missing the point. The development environment is a system, and a pretty complicated one too. It matters where the files are, what's in them, and how they interact. Things change together instead of staying isolated, you add more pieces over time, and even more things need to change together. Anyone who likes text-files more than click-to-configure UIs for tools, will probably like containers more than text files for systems, and for all the same reasons.
Your choices to reproduce complex systems are basically to 1) deny that complexity exists and accept any corresponding limitations in your working environment, 2) follow some error-prone multistep processes to reproduce existing system setup manually, 3) commit to centralizing all development on external cloud platforms, or 4) do something else to bundle together a setup that's repeatable.
I'm strongly in favor of (4) here, and while I'd probably disagree that it requires VMs instead of docker, the goal of repeatable processes is so important that hey, whatever works. It sounds like you're in camp 1 or 2?
This is exactly why I’m using chatGPT codex over Claude Code (even though I suspect CC might be better). Each chat runs in its own cloud based container. There’s no risk of exposing secrets/deleting files/breaking environment. I can run 3 in parallel while I continue to code locally. It works in a branch and integrates via PR. It’s a great DevEx.
Someone please build a nice macOS app using hypervisor framework that lets me do this locally :)
If you are using Claude Code on macOS running it in a devcontainer has a few upsides like fewer cli tool call failures, meaning less waiting time and less context window spam.
But there are some things you lose as well @ ergonomics:
- "done" notifications are not working by default (might be possible trigger and send to host using hooks feature)
- more difficult to give playwright a session (need to get cookies into playwright in the container)
- can't easily paste screenshots into the devcontainer (Claude Code has to take a screenshot or you have to put it into a mounted dir)
and of course the usual advantages of using containers still apply (dependency management, reproducibility and so on).
I still wonder though if nix would allow me to remove the container overhead (they do noticeably tax the macbook battery).
Claude Code using grep is often failing (also in devcontainer but less often). Many command line tools on macOS work subtly different than the ones on linux.
And you don't need to stop there. Claude Code also has great open alternatives you can run in any environment you like, with any model, and under economic arrangements you define. See https://oss-ai-swe.org/ for a few. My current favs are OpenHands and Codex CLI.
Containers do seem to work really well for agents. It lets them run in parallel! Giving them sudo also lets them do interesting things you wouldn’t want them doing on your desktop, eg. installing tools or debugging with tcpdump. (I am working on agent-in-a-container: sketch.dev)
Is this level of fear typical or reasonable? If so, why doesn’t Anthropic / AI code gen providers offer this type of service? Hard to believe Anthropic is not secure in some sense — like what if Claude Code is already inside some container-like thing?
Is it actually true that Claude cannot bust out of the container?
It’s not the fear but the options this gives you to allow Claude Code to iterate at a faster pace. You can also do multiple agents at the same time AND have them communicate to derive at a solution much faster. UX for doing all this is still not desirable. My main issue right now is that Claude Code and other agents iterate incrementally. We need a “waterfill” approach.
Just a month ago, an AI coding agent deleted all the files on someone's computer and there was a little discussion of it here on HN. Support's response was basically "yeah, this happens sometimes".
HN thread (flagged, probably because it was a link to some crappy website that restates things from social media with no substantive content of its own): https://news.ycombinator.com/item?id=44262383
It's worth noting that the default settings of Cursor do prevent this by asking you to confirm every command that is run. And when you get tired of that 5 minutes in and switch to auto-approving there is still protection against files outside the work directory being deleted. The story above is about someone who disabled all the safeguards because they were inconvenient, then bad things happened
It is a good example of "bad things can happen", but when talking about whether we need additional safeguards the lessons are less clear. And while I'm not as familiar with the safeguards of Claude Code I'm assured it also has some by default
I haven't found that to be the case. I have used cc within an container and on the host machine and it has been fine. Any command that could cause changes to your system you MUST approve when using it in agent mode.
I have personally never seen claude (or actually any AI agent) do anything that could not be fixed with git. I run 24/7 in full permissions bypass mode and hardly think about it.
Anyone with more than one toolbox knows that fear isn't required. Containers are about more than security, including stuff like organization and portability.
> If so, why doesn’t Anthropic / AI code gen providers offer this type of service?
Well perhaps I'm too much the cynic, but I'm sure you can imagine why a lack of portability and reproducibility are things that are pretty good for vendors. A lack of transparency also puts the zealots for "100x!", and vendors, and many other people in a natural conspiracy together, and while it benefits them to drum up FOMO it makes everyone else burn time/money trying to figure out how much of the hype is real. People who are new to the industry get leverage by claiming all existing knowledge does not matter, workers who are experienced but looking to pivot into a new specialization in a tough job market benefit from making unverifiable claims, vendors make a quick buck while businesses buy-to-try and forget to cancel the contract, etc etc.
> Is it actually true that Claude cannot bust out of the container?
Escaping containers is something a lot of people in operations and security have spent a lot of time thinking about long before agents and AI. Container escape is possible and deadly serious, but not in this domain really, I mean all your banks and utility providers are probably using Kubernetes so compared to that who cares about maybe leaking source/destroying data on local dev machines or platforms trying to facilitate low-code apps? AI does change things slightly because people will run Ollama/MCP/IDEs on the host, and that's arguably some new surface area to worry about. Sharing sockets and files for inter-agent comms is going to be routine even if everyone says it's bad practice. But of course you could containerize those things too, add a queue, containerize unit-tests, etc
From what I can gather, this is part of the idea/appeal behind something like https://phoenix.new/. The AI Agents have total control over the environment and can use all of the associated system tools as a result, without putting your own machine at risk. Once things are kinda working, you can pull it out and work locally.
I use DevPod [1] to run Claude Code within Docker-based dev container environments, and it's been fairly seamless. It lets me run environments locally and focus Claude's context on just the repo I want it to work on.
Bluefin distro is container/isolation oriented (sort of required given the immutable nature and not wanting to do too much layering) and includes a lot of options to implement a dev environment, including devpod and distrobox/toolbox.
Another idea is to develop in a KASM rootless docker workspace, where distrobox/toolbx can also be at your disposal. KASM workspaces are accessible thru the web, so you can work from anywhere.
The immutable nature of ideas like Bluefin and KASM encourage the user to use brew for package management, which would stay persistent under /home/linuxbrew
Mount them to the local filesystem, maybe even as read-only so Claude cannot modify them.
It actually makes bootstrapping the dev env so much easier too, basically just take a template .devcontainers and you're golden. After that just tell Claude what files you want to mount to the filesystem and restart
Another advantage of running claude inside a container is that you can use "--dangerously-skip-permissions" and let it do a thing in full autonomy for 2 hours. With a good prompt, abundant feedback like centralized logging and tests and a clear Claude.md, it can get pretty far on its own.
I put in a full day trying to get Claude Code and VSCode to work inside Docker. I wasn't able to get the window to properly display in my wayland session.
I don't know if it's appropriate for your case, but devcontainer <https://devcontainer.community/awesome>, code-server, or Eclipse Theia are basically VSCode over http and will mimick the GitHub.dev experience. I'm guessing a lot of your heartburn was trying to get the graphical parts of Electron to operate inside docker but it's really not good at that
I did see the VSCode part, but it might interest you that the JetBrains products also have an rpc style development setup through Gateway, where the product runs effectively headless in the container and just sends the display commands to your local IDE to handle latency sensitive GUI operations
Yeah, I don't think you deserve the down votes for expressing an opinion (except maybe that it doesn't add a lot to the conversation), but speaking from personal experience, the whole AI coding thing has been pretty amazing for me.
I'm technical, I can read code (even write some of it), but actually completing things or getting started on serious projects is really hard: partly because I am not a professional develop (and so everything is hard) and partly because of time constraints. AI agents address both of these concerns very well and I've been able to produce things I wouldn't have thought possible. Are they ready for Prod? Maybe not, but at least they WORK and that's soo much more than anything I've managed in the past.
I swear to you that if you program the way I do you (without any AI tools or even developer tools made after 2005) you will learn 100x more and achieve 100x more
Except you glossed over the part where the person said they lacked time.
There is programming the art and programming to solve a problem. The art is great - I’ve written software for decades. Life dictates I no longer have as much time, but I still want to solve problems. AI helps me do that in the limited that I have.
Fear and resentments. I've seen this not just online but also in conversation with friends. They encouter blogs and Youtube vids about great success with AI agents. Mainstream press articles about how AI is set to eliminate all jobs in 3 years, and mass layoffs in tech because 'AI' (even though we have had the same cyclic boom/bust in tech every 7 years before 'AI', not saying this cycle isn't different though).
They even tried some ChatGTP or Copilot coding themselves, throwing in some vague 'do this' prompt and got bad results. So they decided either "it's all bs hype for losers' or "man, I'm clearly not cut out for this new AI world, hope I can hold out till I can retire"
So every time they see an AI post, they feel the need to wave a '100% pure non AI coder, who's with me?' flag.
Using these, I can SSH into my devserver, use the devcontainer CLI to open a tmux session with iTerm2 Tmux integration, and it feels just like a local window. Combine that with Neovide and remote Neovim over the same channel, and I have a native-feeling dev environment running on a remote devcontainer in a nearby data center.
[0] https://github.com/devcontainers/cli
[1] https://gitlab.com/CGamesPlay/qtm
I have many environments locally, some dependent on others, and some require local databases. I use containers in production, but not always locally.
It’s almost a hellscape situation for trying to setup a fully isolated dev environment. I might be able have have some future generation of Claude convert my existing dev setup to something isolated with k8s. But, I don’t have the power to run such an environment locally, with all of the apps and services. I’d need to set my dev environments up in the cloud, but I don’t have enough money to pay for that, and it wouldn’t even work in some circumstances, because some things must run locally.
So, instead I run Cursor AI with various MCP servers, I approve tool calls, I don’t have things isolated, and I know this will eventually bite me.
https://devpod.sh/
I use a simple script that copies my working directory into a container, prompts Claude Code, and then either saves a planning document locally, or opens a pull request in GitHub for me to review.
I quite like this because it makes starting agents when I have ideas really frictionless, and then I can easily discard the results and try again if it went off the rails. The Max plan makes me not worry about the cost of this whole process as well.
I also set up containers initially out of caution, but honestly, I've never seen Claude Code do anything that git couldn't easily reverse, so I'm not that worried about that any more.
It's just a Dockerfile that installs dependencies, an entrypoint that invokes claude, and some wrapper scripts that handle creating the container, passing through the prompt, and managing the results (e.g., output markdown to a directory, or open a PR). For input/output from the container I mount directories within the Docker container to local directories under ~/.call_claude/. I create a directory under there, clone the source code to it, output the prompt to a text file, and then grab results from that directory after Claude Code has finished running.
1. Apple container: https://github.com/apple/container
2. CodeRunner: https://github.com/BandarLabs/coderunner
Caveat: You need M1/M2/M3/M4 mac for this to work. MacOS 26 is optional but recommended.
It's worth thinking about reproducibility even if you're not concerned about security. We would not have to argue so much about the effectiveness of something like vibe-coding if everyone could simply share process/tooling without tons of custom setup. And even if you're not worried about filesystem sandboxing and leaking secrets like ssh keys, even if versioning with git is enough of an undo button for you.. who wants to clutter their whole system with a ton of new language stacks and/or weird dependencies for every small experiment? Most experiments with the new hotness are going to fail, so we should expect to do a lot..
I‘d argue the reproducible parts of vibe coding (agentic engineering) setups are just text files. Many people use a mix of web apps (AI studio), Mac apps (Wispr Flow), and other UI tools (repo prompt) in their workflow which can’t be put in a container anyway - well, reasonably at least.
If you want security, containers won’t get you that far. You’ll need to use a VM.
But if you give Claude Code access to your GitHub repo, what else is there worth protecting, that’s not protected by keychain & sudo?
Your choices to reproduce complex systems are basically to 1) deny that complexity exists and accept any corresponding limitations in your working environment, 2) follow some error-prone multistep processes to reproduce existing system setup manually, 3) commit to centralizing all development on external cloud platforms, or 4) do something else to bundle together a setup that's repeatable.
I'm strongly in favor of (4) here, and while I'd probably disagree that it requires VMs instead of docker, the goal of repeatable processes is so important that hey, whatever works. It sounds like you're in camp 1 or 2?
Someone please build a nice macOS app using hypervisor framework that lets me do this locally :)
But there are some things you lose as well @ ergonomics:
- "done" notifications are not working by default (might be possible trigger and send to host using hooks feature)
- more difficult to give playwright a session (need to get cookies into playwright in the container)
- can't easily paste screenshots into the devcontainer (Claude Code has to take a screenshot or you have to put it into a mounted dir)
and of course the usual advantages of using containers still apply (dependency management, reproducibility and so on).
I still wonder though if nix would allow me to remove the container overhead (they do noticeably tax the macbook battery).
Is this level of fear typical or reasonable? If so, why doesn’t Anthropic / AI code gen providers offer this type of service? Hard to believe Anthropic is not secure in some sense — like what if Claude Code is already inside some container-like thing?
Is it actually true that Claude cannot bust out of the container?
https://docs.anthropic.com/en/docs/claude-code/devcontainer
and an example repo
https://github.com/anthropics/claude-code/tree/main/.devcont...
Just a month ago, an AI coding agent deleted all the files on someone's computer and there was a little discussion of it here on HN. Support's response was basically "yeah, this happens sometimes".
forum post: https://forum.cursor.com/t/cursor-yolo-deleted-everything-in...
HN thread (flagged, probably because it was a link to some crappy website that restates things from social media with no substantive content of its own): https://news.ycombinator.com/item?id=44262383
Idk how Claude Code works in particular, though.
It is a good example of "bad things can happen", but when talking about whether we need additional safeguards the lessons are less clear. And while I'm not as familiar with the safeguards of Claude Code I'm assured it also has some by default
It is like insurance, 99.95% of the time you don't need it. But when you do, you wish you had it.
Anyone with more than one toolbox knows that fear isn't required. Containers are about more than security, including stuff like organization and portability.
> If so, why doesn’t Anthropic / AI code gen providers offer this type of service?
Well perhaps I'm too much the cynic, but I'm sure you can imagine why a lack of portability and reproducibility are things that are pretty good for vendors. A lack of transparency also puts the zealots for "100x!", and vendors, and many other people in a natural conspiracy together, and while it benefits them to drum up FOMO it makes everyone else burn time/money trying to figure out how much of the hype is real. People who are new to the industry get leverage by claiming all existing knowledge does not matter, workers who are experienced but looking to pivot into a new specialization in a tough job market benefit from making unverifiable claims, vendors make a quick buck while businesses buy-to-try and forget to cancel the contract, etc etc.
> Is it actually true that Claude cannot bust out of the container?
Escaping containers is something a lot of people in operations and security have spent a lot of time thinking about long before agents and AI. Container escape is possible and deadly serious, but not in this domain really, I mean all your banks and utility providers are probably using Kubernetes so compared to that who cares about maybe leaking source/destroying data on local dev machines or platforms trying to facilitate low-code apps? AI does change things slightly because people will run Ollama/MCP/IDEs on the host, and that's arguably some new surface area to worry about. Sharing sockets and files for inter-agent comms is going to be routine even if everyone says it's bad practice. But of course you could containerize those things too, add a queue, containerize unit-tests, etc
[1]: https://devpod.sh/
https://docs.projectbluefin.io/bluefin-dx/
Another idea is to develop in a KASM rootless docker workspace, where distrobox/toolbx can also be at your disposal. KASM workspaces are accessible thru the web, so you can work from anywhere.
The immutable nature of ideas like Bluefin and KASM encourage the user to use brew for package management, which would stay persistent under /home/linuxbrew
https://hub.docker.com/r/linuxserver/kasm
https://kasmweb.com/docs/latest/how_to/docker_in_kasm.html
https://gist.github.com/jgbrwn/28645fcf4ac5a4176f715a6f9b170...
It actually makes bootstrapping the dev env so much easier too, basically just take a template .devcontainers and you're golden. After that just tell Claude what files you want to mount to the filesystem and restart
Also can we please differentiate vibe coding and prompt based development.
There is a difference between prompting "write me a website" and just using the LLM for typing faster than you do.
I did see the VSCode part, but it might interest you that the JetBrains products also have an rpc style development setup through Gateway, where the product runs effectively headless in the container and just sends the display commands to your local IDE to handle latency sensitive GUI operations
404
I'm technical, I can read code (even write some of it), but actually completing things or getting started on serious projects is really hard: partly because I am not a professional develop (and so everything is hard) and partly because of time constraints. AI agents address both of these concerns very well and I've been able to produce things I wouldn't have thought possible. Are they ready for Prod? Maybe not, but at least they WORK and that's soo much more than anything I've managed in the past.
There is programming the art and programming to solve a problem. The art is great - I’ve written software for decades. Life dictates I no longer have as much time, but I still want to solve problems. AI helps me do that in the limited that I have.
If there's a post about Zig, you don't see people saying how they don't use Zig.
They even tried some ChatGTP or Copilot coding themselves, throwing in some vague 'do this' prompt and got bad results. So they decided either "it's all bs hype for losers' or "man, I'm clearly not cut out for this new AI world, hope I can hold out till I can retire"
So every time they see an AI post, they feel the need to wave a '100% pure non AI coder, who's with me?' flag.
60's movements would not be possible in current times.
would not be possible, indeed