Live data from Hacker News

Switching to Claude Code and VSCode Inside Docker

timsh.org

51–60 of 170 posts

Re: Switching to Claude Code and VSCode Inside Docker

#51
post #33

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…

I never have tool calls failing on macOS. What tool calls are failing for you?

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.

Re: Switching to Claude Code and VSCode Inside Docker

#52

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…

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.

Re: Switching to Claude Code and VSCode Inside Docker

#54
post #37

[flagged]

Why is it that in every Claude Code related submission there's people proudly declaring out-of-context they are not using AI tools? If there's a post about Zig, you don't see people saying how they don't use Zig.

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.

Re: Switching to Claude Code and VSCode Inside Docker

#55

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…

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.

Re: Switching to Claude Code and VSCode Inside Docker

#56

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?

re Anthropic: there is a whole docs section on devcontainers

https://docs.anthropic.com/en/docs/claude-code/devcontainer

and an example repo

https://github.com/anthropics/claude-code/tree/main/.devcont...

Re: Switching to Claude Code and VSCode Inside Docker

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

Re: Switching to Claude Code and VSCode Inside Docker

#58
post #42

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…

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…

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?

Re: Switching to Claude Code and VSCode Inside Docker

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

Re: Switching to Claude Code and VSCode Inside Docker

#60

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?

[deleted]
Post reply on HN