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 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.
You could… not do this. You know it causes you problems, you consider it unfortunate that you’re becoming more reliant on it, and yet for some reason you’re choosing to continue anyway. Why are you doing that?
What are some reasons to hate VSCode?
That's not to say it's especially buggy, it's just so large, there are a lot of places for bugs to hide.
I get distracted by the impulse to contribute to other editors also, but those are contributions that I'm happy about. They don't always result in bugs fixed or features added, sometimes somebody says "no" but at least it resolves in some way. With VSCode it feels like I'm going in circles.
- The push to use Github Copilot and no option to disable that crap.
I wish there was a fork of VSCode with all the telemetry and all of the proprietary crap disabled with 100% extension support...
Through the use of amazing PR they have made people forget about their Embrace, extend, and extinguish strategy with open source.
Now the way I did port forwarding was really wild and really complicated and I think that it might demand a blog post if I am being honest, but yes this project is absolutely godsend. Thanks!!
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.
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 had one agent that installed something with pip and used it to rewrite my git history. It used the wrong flag and what was left was one file. I am glad I caught it before auto-commit and push triggered. It was one of my hobby projects, so not a huge deal. I can't imagine the fallout of this happening in a work environment.
alias claude-docker='docker run --mount type=bind,source=/Users/hboon/.claude,target=/home/node/.claude --mount type=bind,source=/Users/hboon/.claude.json,target=/home/node/.claude.json --mount type=bind,source=.,target=/workspace/project --workdir /workspace/project -it cc /usr/bin/fish'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.
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?
- /home/me -- 660 default permissions
- /home/me/project -- owner "claude", add "me" to "claude" group
- symlink /home/claude/project to /home/me/project
- Run claude in different user session
- Use CTRL+ALT+F2 to immediately switch between my main and claude sessions. Claude continues working in the background.
Someone please build a nice macOS app using hypervisor framework that lets me do this locally :)
Containerisation solved the "Works on my machine" gap between local and prod. This is just solving for the same gap between Dev 1 and Dev 2.
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).
I really want to limit the amount of software I am installing on my main system due to possible security issues.
I have recently moved to a VM only development workflow, but still feeling some growing pains as I figure out a good setup. I run my IDE in the guest, which is kind of crummy - responsiveness is worse + the VMs are a lot heavier than a headless code setup would be. I have thought about using a Flatpak IDE with filesystem access disabled as a potential middle ground solution so that the guests could be minimal images connected by SSH.
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?
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
https://docs.anthropic.com/en/docs/claude-code/devcontainer
and an example repo
https://github.com/anthropics/claude-code/tree/main/.devcont...
--cap-add=NET_RAW
https://github.com/anthropics/claude-code/blob/main/.devcont...
If the cointainer route (with those types of privileges) is being suggested from a security point of view, then might as well run these processes in a VM and call it a day :/
You also have MCP tools running on your machine, which might have security issues.
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
Of course. Also with regular customer projects. Even without AI--but of course having an idiot be able to execute commands on your PC makes the risk higher.
> If so, why doesn’t Anthropic / AI code gen providers offer this type of service?
Why? Separate the concerns. Isolation is a concern depending on my own risk appetite. I do not want stuff to decide on my behalf what's inside the container and what's outside. That said, they do have devcontainer support (like the article says).
>Hard to believe Anthropic is not secure in some sense — like what if Claude Code is already inside some container-like thing?
It's a node program. It does ask you about every command it's gonna execute before it does it, though.
>Is it actually true that Claude cannot bust out of the container?
There are (sporadic) container escape exploits--but it's much harder than not having a container.
You can also use a qemu vm. Good luck escaping that.
Or an extra user account--I'm thinking of doing that next.
if it did, it would be too late, wouldn't it?
Yet. You haven't had a single issue yet.
The history of computing says that everything is a porous security boundary just waiting for a motivated individual to attack it. Defense in layers, especially in the wild west of AI where everybody is playing move fast and break things at breakneck speed.
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
[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...
To me it seems like the only reason to fiddle with docker is if your dev env is already in a container
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.
has anyone faced this?
However, if you are familiar with Pliny the Liberator's work, essentially all modern models are easily jailbroken, such that the original prompt can be overridden. All it will take for your agent is to download a malicious payload, perhaps disguised as a relevant library or documentation for the task at hand, and it can be running whatever the attacker tells it.
An 'rm -rf /' would be a pretty mild outcome. The more likely one would be the attacker silently installs malware on your machine.
I would like to run everything in container and fire up two or three CC at once. It might be best actually. Right now I'm doing local dev with many services in one container and Claude sometimes doesn't use the container properly. I probably waste a lot of cycles with CC relearning my setup often as it struggles through it.
60's movements would not be possible in current times.