9 ms·

Switching to Claude Code and VSCode Inside Docker

265 points by timsh 1y ago

jMyles 1y ago
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.
- dymk 1y ago
  Are you using devcontainers? The vscode UI doesn’t run in docker, but a remote server does.
- mdaniel 1y ago
  I don't know if it's appropriate for your case, but devcontainer <https://devcontainer.community/awesome 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
  - andsoitis 1y ago
    > but devcontainer <https://devcontainer.community/awesome https://devcontainer.community/awesome>, 404
    - CallMeJim 1y ago
      Here's the intended link target: https://github.com/devcontainer-community/awesome-devcontainer https://github.com/devcontainer-community/awesome-devcontain...
- skydhash 1y ago
  You need to share the wayland socket (how programs talk to the compositor) with the container in docker. I’ve seen a script that does that on GitHub but I can’t remember the name. Distrobox and Toolbx also does this, but they also share your home directory with the container because that’s where all your config are.
chickenzzzzu 1y ago
[flagged]
- cdelsolar 1y ago
  You’re missing out
- abrookewood 1y ago
  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.
  - chickenzzzzu 1y ago
    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
    - matwood 1y ago
      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.
      - chickenzzzzu 1y ago
        The fatal flaw in your theory is that Docker, Claude, and whoever else will add an infinite amount of time spent debugging once you have a sufficiently complex problem, which is usually within 1-7 days of using it. Please explain to me how I'm wrong. in the event you don't want to hear how I'm right, I am forstalling that while waiting for your reply
tartakovsky 1y ago
2-ish questions: 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?
- kxrm 1y ago
  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.
- extr 1y ago
  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.
  - swayson 1y ago
    Correlation does not equal causation as the old adage goes. Just because if you havent seen the pattern, doesn't mean it can't. It is like insurance, 99.95% of the time you don't need it. But when you do, you wish you had it.
- photonthug 1y ago
  > Is this level of fear typical or reasonable? 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
CGamesPlay 1y ago
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. [0] https://github.com/devcontainers/cli https://github.com/devcontainers/cli [1] https://gitlab.com/CGamesPlay/qtm https://gitlab.com/CGamesPlay/qtm
- shepherdjerred 1y ago
  devpod is quite nice for this https://devpod.sh/ https://devpod.sh/
  - brabel 1y ago
    Just tried it... and it says it's client-only, but when I try to run the SSH provider using my Rapberry Pi it says it needs `docker` to be installed on it :/. So it's not just client-only, is it?
    - deleted 1y ago
      [deleted]
    - adastra22 1y ago
      Isn't that what client-only means?
      - brabel 1y ago
        Like, oh you need to install this extremely heavy tool on your server... but yeah it's still client-only, trust me?
sothatsit 1y ago
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.
- anon7000 1y ago
  Even locally, Claude in multiple terminal tabs/windows can do different tasks in parallel
  - sothatsit 1y ago
    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.
    - wahnfrieden 1y ago
      Isn't there tooling for helping to manage this
- extr 1y ago
  Any interest in sharing the script?
  - sothatsit 1y ago
    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.
photonthug 1y ago
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..
- manmal 1y ago
  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?
  - photonthug 1y ago
    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?
crawshaw 1y ago
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)
abrookewood 1y ago
From what I can gather, this is part of the idea/appeal behind something like https://phoenix.new/ 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.
pjmlp 1y ago
This kind of behaviour is hilarious, either use the tools with their caveats, or actually make a stand by not using them. 60's movements would not be possible in current times.
- wutwutwat 1y ago
  "accept things how they are, or give up" would not be possible, indeed
  - pjmlp 1y ago
    Standing up is not giving up, thanks for confirming my remark.
intellectronica 1y ago
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/ https://oss-ai-swe.org/ for a few. My current favs are OpenHands and Codex CLI.
- manmal 1y ago
  Aren’t those _way_ more expensive per token?
  - swader999 1y ago
    Yes and I really hope more models consider pricing like Claude Max. There's also the option of choosing local models but I haven't tried that yet. Claude is just too good to spend time elsewhere (at the moment).
    - intellectronica 1y ago
      TANSTAAFL https://everything.intellectronica.net/p/all-you-can-eat-economics-for-ai-coders https://everything.intellectronica.net/p/all-you-can-eat-eco...
  - anuramat 1y ago
    you can use your claude code subscription with opencode (not sure how "legal" that is); github copilot straight up provides an api (very "legal")
  - intellectronica 1y ago
    How so? Claude is the most expensive. With open tools you can choose whatever model delivers the best results for the budget you have.
ubj 1y ago
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. [1]: https://devpod.sh/ https://devpod.sh/
- thelittleone 1y ago
  Interesting. Works with claude max or API only?
  - ubj 1y ago
    I use Claude Max with it. Haven't personally tried the API yet.
- indigodaddy 1y ago
  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. https://docs.projectbluefin.io/bluefin-dx/ 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://hub.docker.com/r/linuxserver/kasm https://kasmweb.com/docs/latest/how_to/docker_in_kasm.html https://kasmweb.com/docs/latest/how_to/docker_in_kasm.html https://gist.github.com/jgbrwn/28645fcf4ac5a4176f715a6f9b1702ab https://gist.github.com/jgbrwn/28645fcf4ac5a4176f715a6f9b170...
hosolmaz 1y ago
This is the idea I had in mind while doing https://github.com/textcortex/claude-code-sandbox https://github.com/textcortex/claude-code-sandbox
tosh 1y ago
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).
- artdigital 1y ago
  I never have tool calls failing on macOS. What tool calls are failing for you?
  - tosh 1y ago
    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.
    - singularity2001 1y ago
      can't you easily circumvent this by telling it to use the Mac versions in the prompt.md
restrictedolly 1y ago
How can I preserve the local configuration files I have with this container? (the custom slash commands, config.json etc)
- ffsm8 1y ago
  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
BiteCode_dev 1y ago
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.
mkagenius 1y ago
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. 1. Apple container: https://github.com/apple/container https://github.com/apple/container 2. CodeRunner: https://github.com/BandarLabs/coderunner https://github.com/BandarLabs/coderunner Caveat: You need M1/M2/M3/M4 mac for this to work. MacOS 26 is optional but recommended.
- singularity2001 1y ago
  TIL you can just run the container command with an existing docker file
khalic 1y ago
I'm ashamed I didn't think of it. Great article, thank you! 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.
scosman 1y ago
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 :)
lvl155 1y ago
This is my approach but it wasn’t all smooth especially with MCPs. 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.
- twalla 1y ago
  Try colima or rancher desktop
hintymad 1y ago
Honest question: why do people prefer developing code inside a docker? I get the benefits of docker as a deployment unit, but wouldn’t configuring a dev container and using it a hassle nonetheless, compared to not doing them at all?
- deleted 1y ago
  [deleted]
- magic_hamster 1y ago
  Separation of dependencies and ability to easily interconnect containers.
- blurrybird 1y ago
  If you commit the .devcontainer.json and associated files your whole team gets a consistent, local-feeling, environment for free. 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.
  - globular-toast 1y ago
    That's a different thing. You're talking about running the software under development in a container. I think the commenter was asking about running the dev tooling in a container, which I find a massive pain.
    - dymk 1y ago
      No, that’s what they’re talking about - running the tooling in a container. Dev tool chains are a pain in the ass to keep consistent in even small teams. Devcontainers solve that.
  - ColonelPhantom 1y ago
    Devcontainers don't "feel" local to me, since my CLI tools are not available in them. Think ripgrep or fd, for example.
ed_mercer 1y ago
I don't get these posts. I'm using claude --dangerously-skip-permissions all day and haven't had a single issue. In my experience it doesn't just randomly start erasing your hard drives. Also having a proper CLAUDE.md probably helps.
- nikolayasdf123 1y ago
  > it doesn't just randomly start erasing your hard drives. if it did, it would be too late, wouldn't it?
- singularity2001 1y ago
  I understand some of the motivation for this post but in my view it's exaggerated because Claude code does a good job asking for permissions and in the (reasonable)worst case you can probably get an old state from github. If for some reason Claude (or someone) wants to take over your whole system I'm not sure if Dockers would stop it
- adastra22 1y ago
  > I'm using claude --dangerously-skip-permissions all day and haven't had a single issue. Yet. You haven't had a single issue yet.
  - mceachen 1y ago
    Correct. The number of times I’ve had Claude ask permission to rm -rf paths with .. elements is more than zero.
    - adastra22 1y ago
      I have in fact had Claude (running on Cursor) do the equivalent of rm -rf /. It happens.
- 3eb7988a1663 1y ago
  You ignore safety features unless you have already experienced disaster? Do you wear a seat belt? Run all commands as root? 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.
asadm 1y ago
i don’t get the worry. i run these models all day without any sandbox and even leave them running while i walk away. i haven’t had a rm -rf kind of situation ever or even a hint of model going towards it. even gemini 2.5 at it’s lowest doesn’t do that. has anyone faced this?
- Yiin 1y ago
  same, it actually annoys me when some calls need sudo access and I need to handle it manually, I have no idea what people are doing with those tools to fear destructive actions on the system
- FlyingAvatar 1y ago
  Just because unintended things aren't happening right now, doesn't mean they won't happen. We are in the honeymoon phase of this technology where mass exploitation isn't yet being attempted. 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.
- adastra22 1y ago
  "I leave my door unlocked all day, sometimes when I'm not even home. I've never had anyone rob my house. Has anyone faced this?"
- swader999 1y ago
  I mistakenly started Claude in my root dev folder in dangerously skip mode the other day. Asked it to fix my playwright tests. All hell broke loose and I couldn't stop it. Lol. Eventually got it shut down and all was fine. Scared me though. There's a hook you can easily implement for RM -rf, see indydevdan on YouTube, he has a nice repo of it. 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.
tkiolp4 1y ago
I thought it was more commonplace to develop inside containers or vms. I don’t trust running npm or pip or gradle or go install in my own machine.
- graton 1y ago
  I use VMs myself. I use Proxmox and have it setup so that I can spin up a fresh VM in around 10-20 seconds when needed. I also like that I can take snapshots. I really want to limit the amount of software I am installing on my main system due to possible security issues.
  - 3eb7988a1663 1y ago
    Do you have any example scripts for your setup? 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.
    - graton 1y ago
      I have taken cloud images and set them up with 'cloud-init'. So I can bring them up very quickly.
hmcamp 1y ago
Thanks
anuramat 1y ago
I can highly recommend bubblewrap for sandboxing -- configuration is just CLI arguments, one per a mounted path; I use a little script that mounts CWD, claude stuff, and XDG data directories in RW, and the rest in RO. To me it seems like the only reason to fiddle with docker is if your dev env is already in a container
globular-toast 1y ago
Wait, Claude Code isn't even open source? What year is it?! And people are letting this thing run commands directly on their workstations? Crazy...
the__alchemist 1y ago
What drives this degree of user-experience complexity? Is there a targeted workflow that VsCode and Claude did not include in their GUI, that motivates this solution. Is it a tinkerer mindset, where setting this up is a fun activity for the author and readers?
arscan 1y ago
This setup is also compatible with GitHub CodeSpaces, which I think is an exceptionally nice development experience if you are on something like a Chromebook, and gives you isolation from your local network. Also lets you share your app running in dev-mode with anyone for feedback, without having to poke holes in your network or whatever. Also also, you can use the Cline extension in this environment if you still want the cursor-style copilotey experience.
kaffekaka 1y ago
Letting Claude Code loose on my home folder feels bad yes. Would using a separate user account solve it? I.e. keep git repos in for example /home/claude and run claude as that user? Or am I missing something?
- eblanshey 1y ago
  I do pretty much this. - /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.
eabeezxjc 1y ago
[flagged]
thisistemp001 1y ago
I started working with VSCode in container ~3 years ago [1], at first I just felt I'd like to have control over the environment but later it made more sense when I switched to codeium windsurf [2]- I thought it's safer not to let agent loose in my filesystem [1] https://github.com/grzegorzk/vscode_in_podman https://github.com/grzegorzk/vscode_in_podman [2] https://github.com/grzegorzk/codeium_windsurf_in_podman https://github.com/grzegorzk/codeium_windsurf_in_podman

265 points by timsh 1y ago

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.

dymk 1y ago
Are you using devcontainers? The vscode UI doesn’t run in docker, but a remote server does.
mdaniel 1y ago
I don't know if it's appropriate for your case, but devcontainer <https://devcontainer.community/awesome 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
- andsoitis 1y ago
  > but devcontainer <https://devcontainer.community/awesome https://devcontainer.community/awesome>, 404
  - CallMeJim 1y ago
    Here's the intended link target: https://github.com/devcontainer-community/awesome-devcontainer https://github.com/devcontainer-community/awesome-devcontain...
skydhash 1y ago
You need to share the wayland socket (how programs talk to the compositor) with the container in docker. I’ve seen a script that does that on GitHub but I can’t remember the name. Distrobox and Toolbx also does this, but they also share your home directory with the container because that’s where all your config are.

chickenzzzzu 1y ago

[flagged]

cdelsolar 1y ago
You’re missing out
abrookewood 1y ago
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.
- chickenzzzzu 1y ago
  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
  - matwood 1y ago
    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.
    - chickenzzzzu 1y ago
      The fatal flaw in your theory is that Docker, Claude, and whoever else will add an infinite amount of time spent debugging once you have a sufficiently complex problem, which is usually within 1-7 days of using it. Please explain to me how I'm wrong. in the event you don't want to hear how I'm right, I am forstalling that while waiting for your reply

tartakovsky 1y ago

2-ish questions: 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?

kxrm 1y ago
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.
extr 1y ago
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.
- swayson 1y ago
  Correlation does not equal causation as the old adage goes. Just because if you havent seen the pattern, doesn't mean it can't. It is like insurance, 99.95% of the time you don't need it. But when you do, you wish you had it.
photonthug 1y ago
> Is this level of fear typical or reasonable? 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

CGamesPlay 1y ago

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. [0] https://github.com/devcontainers/cli https://github.com/devcontainers/cli [1] https://gitlab.com/CGamesPlay/qtm https://gitlab.com/CGamesPlay/qtm

shepherdjerred 1y ago
devpod is quite nice for this https://devpod.sh/ https://devpod.sh/
- brabel 1y ago
  Just tried it... and it says it's client-only, but when I try to run the SSH provider using my Rapberry Pi it says it needs `docker` to be installed on it :/. So it's not just client-only, is it?
  - deleted 1y ago
    [deleted]
  - adastra22 1y ago
    Isn't that what client-only means?
    - brabel 1y ago
      Like, oh you need to install this extremely heavy tool on your server... but yeah it's still client-only, trust me?

sothatsit 1y ago

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.

anon7000 1y ago
Even locally, Claude in multiple terminal tabs/windows can do different tasks in parallel
- sothatsit 1y ago
  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.
  - wahnfrieden 1y ago
    Isn't there tooling for helping to manage this
extr 1y ago
Any interest in sharing the script?
- sothatsit 1y ago
  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.

photonthug 1y ago

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..

manmal 1y ago
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?
- photonthug 1y ago
  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?

crawshaw 1y ago

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)

abrookewood 1y ago

From what I can gather, this is part of the idea/appeal behind something like https://phoenix.new/ 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.

pjmlp 1y ago

This kind of behaviour is hilarious, either use the tools with their caveats, or actually make a stand by not using them. 60's movements would not be possible in current times.

wutwutwat 1y ago
"accept things how they are, or give up" would not be possible, indeed
- pjmlp 1y ago
  Standing up is not giving up, thanks for confirming my remark.

intellectronica 1y ago

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/ https://oss-ai-swe.org/ for a few. My current favs are OpenHands and Codex CLI.

manmal 1y ago
Aren’t those _way_ more expensive per token?
- swader999 1y ago
  Yes and I really hope more models consider pricing like Claude Max. There's also the option of choosing local models but I haven't tried that yet. Claude is just too good to spend time elsewhere (at the moment).
  - intellectronica 1y ago
    TANSTAAFL https://everything.intellectronica.net/p/all-you-can-eat-economics-for-ai-coders https://everything.intellectronica.net/p/all-you-can-eat-eco...
- anuramat 1y ago
  you can use your claude code subscription with opencode (not sure how "legal" that is); github copilot straight up provides an api (very "legal")
- intellectronica 1y ago
  How so? Claude is the most expensive. With open tools you can choose whatever model delivers the best results for the budget you have.

ubj 1y ago

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. [1]: https://devpod.sh/ https://devpod.sh/

thelittleone 1y ago
Interesting. Works with claude max or API only?
- ubj 1y ago
  I use Claude Max with it. Haven't personally tried the API yet.
indigodaddy 1y ago
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. https://docs.projectbluefin.io/bluefin-dx/ 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://hub.docker.com/r/linuxserver/kasm https://kasmweb.com/docs/latest/how_to/docker_in_kasm.html https://kasmweb.com/docs/latest/how_to/docker_in_kasm.html https://gist.github.com/jgbrwn/28645fcf4ac5a4176f715a6f9b1702ab https://gist.github.com/jgbrwn/28645fcf4ac5a4176f715a6f9b170...

hosolmaz 1y ago

This is the idea I had in mind while doing https://github.com/textcortex/claude-code-sandbox https://github.com/textcortex/claude-code-sandbox

tosh 1y ago

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).

artdigital 1y ago
I never have tool calls failing on macOS. What tool calls are failing for you?
- tosh 1y ago
  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.
  - singularity2001 1y ago
    can't you easily circumvent this by telling it to use the Mac versions in the prompt.md

restrictedolly 1y ago

How can I preserve the local configuration files I have with this container? (the custom slash commands, config.json etc)

ffsm8 1y ago
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

BiteCode_dev 1y ago

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.

mkagenius 1y ago

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. 1. Apple container: https://github.com/apple/container https://github.com/apple/container 2. CodeRunner: https://github.com/BandarLabs/coderunner https://github.com/BandarLabs/coderunner Caveat: You need M1/M2/M3/M4 mac for this to work. MacOS 26 is optional but recommended.

singularity2001 1y ago
TIL you can just run the container command with an existing docker file

khalic 1y ago

I'm ashamed I didn't think of it. Great article, thank you! 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.

scosman 1y ago

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 :)

lvl155 1y ago

This is my approach but it wasn’t all smooth especially with MCPs. 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.

twalla 1y ago
Try colima or rancher desktop

hintymad 1y ago

Honest question: why do people prefer developing code inside a docker? I get the benefits of docker as a deployment unit, but wouldn’t configuring a dev container and using it a hassle nonetheless, compared to not doing them at all?

deleted 1y ago
[deleted]
magic_hamster 1y ago
Separation of dependencies and ability to easily interconnect containers.
blurrybird 1y ago
If you commit the .devcontainer.json and associated files your whole team gets a consistent, local-feeling, environment for free. 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.
- globular-toast 1y ago
  That's a different thing. You're talking about running the software under development in a container. I think the commenter was asking about running the dev tooling in a container, which I find a massive pain.
  - dymk 1y ago
    No, that’s what they’re talking about - running the tooling in a container. Dev tool chains are a pain in the ass to keep consistent in even small teams. Devcontainers solve that.
- ColonelPhantom 1y ago
  Devcontainers don't "feel" local to me, since my CLI tools are not available in them. Think ripgrep or fd, for example.

ed_mercer 1y ago

I don't get these posts. I'm using claude --dangerously-skip-permissions all day and haven't had a single issue. In my experience it doesn't just randomly start erasing your hard drives. Also having a proper CLAUDE.md probably helps.

nikolayasdf123 1y ago
> it doesn't just randomly start erasing your hard drives. if it did, it would be too late, wouldn't it?
singularity2001 1y ago
I understand some of the motivation for this post but in my view it's exaggerated because Claude code does a good job asking for permissions and in the (reasonable)worst case you can probably get an old state from github. If for some reason Claude (or someone) wants to take over your whole system I'm not sure if Dockers would stop it
adastra22 1y ago
> I'm using claude --dangerously-skip-permissions all day and haven't had a single issue. Yet. You haven't had a single issue yet.
- mceachen 1y ago
  Correct. The number of times I’ve had Claude ask permission to rm -rf paths with .. elements is more than zero.
  - adastra22 1y ago
    I have in fact had Claude (running on Cursor) do the equivalent of rm -rf /. It happens.
3eb7988a1663 1y ago
You ignore safety features unless you have already experienced disaster? Do you wear a seat belt? Run all commands as root? 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.

asadm 1y ago

i don’t get the worry. i run these models all day without any sandbox and even leave them running while i walk away. i haven’t had a rm -rf kind of situation ever or even a hint of model going towards it. even gemini 2.5 at it’s lowest doesn’t do that. has anyone faced this?

Yiin 1y ago
same, it actually annoys me when some calls need sudo access and I need to handle it manually, I have no idea what people are doing with those tools to fear destructive actions on the system
FlyingAvatar 1y ago
Just because unintended things aren't happening right now, doesn't mean they won't happen. We are in the honeymoon phase of this technology where mass exploitation isn't yet being attempted. 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.
adastra22 1y ago
"I leave my door unlocked all day, sometimes when I'm not even home. I've never had anyone rob my house. Has anyone faced this?"
swader999 1y ago
I mistakenly started Claude in my root dev folder in dangerously skip mode the other day. Asked it to fix my playwright tests. All hell broke loose and I couldn't stop it. Lol. Eventually got it shut down and all was fine. Scared me though. There's a hook you can easily implement for RM -rf, see indydevdan on YouTube, he has a nice repo of it. 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.

tkiolp4 1y ago

I thought it was more commonplace to develop inside containers or vms. I don’t trust running npm or pip or gradle or go install in my own machine.

graton 1y ago
I use VMs myself. I use Proxmox and have it setup so that I can spin up a fresh VM in around 10-20 seconds when needed. I also like that I can take snapshots. I really want to limit the amount of software I am installing on my main system due to possible security issues.
- 3eb7988a1663 1y ago
  Do you have any example scripts for your setup? 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.
  - graton 1y ago
    I have taken cloud images and set them up with 'cloud-init'. So I can bring them up very quickly.

hmcamp 1y ago

Thanks

anuramat 1y ago

I can highly recommend bubblewrap for sandboxing -- configuration is just CLI arguments, one per a mounted path; I use a little script that mounts CWD, claude stuff, and XDG data directories in RW, and the rest in RO. To me it seems like the only reason to fiddle with docker is if your dev env is already in a container

globular-toast 1y ago

Wait, Claude Code isn't even open source? What year is it?! And people are letting this thing run commands directly on their workstations? Crazy...

the__alchemist 1y ago

What drives this degree of user-experience complexity? Is there a targeted workflow that VsCode and Claude did not include in their GUI, that motivates this solution. Is it a tinkerer mindset, where setting this up is a fun activity for the author and readers?

arscan 1y ago

This setup is also compatible with GitHub CodeSpaces, which I think is an exceptionally nice development experience if you are on something like a Chromebook, and gives you isolation from your local network. Also lets you share your app running in dev-mode with anyone for feedback, without having to poke holes in your network or whatever. Also also, you can use the Cline extension in this environment if you still want the cursor-style copilotey experience.

kaffekaka 1y ago

Letting Claude Code loose on my home folder feels bad yes. Would using a separate user account solve it? I.e. keep git repos in for example /home/claude and run claude as that user? Or am I missing something?

eblanshey 1y ago
I do pretty much this. - /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.

eabeezxjc 1y ago

[flagged]

thisistemp001 1y ago

I started working with VSCode in container ~3 years ago [1], at first I just felt I'd like to have control over the environment but later it made more sense when I switched to codeium windsurf [2]- I thought it's safer not to let agent loose in my filesystem [1] https://github.com/grzegorzk/vscode_in_podman https://github.com/grzegorzk/vscode_in_podman [2] https://github.com/grzegorzk/codeium_windsurf_in_podman https://github.com/grzegorzk/codeium_windsurf_in_podman