[HN Gopher] Claude Cowork runs Linux VM via Apple virtualization...
___________________________________________________________________
Claude Cowork runs Linux VM via Apple virtualization framework
Author : jumploops
Score : 72 points
Date : 2026-01-14 07:21 UTC (1 days ago)
(HTM) web link (gist.github.com)
(TXT) w3m dump (gist.github.com)
| lysace wrote:
| Is there an easy way to do something similar for Claude Code? I'm
| growing tired of babysitting it to make sure it doesn't do
| anything bad.
|
| Late adopter. Started last night. Stayed up four hours past my
| normal bedtime because I couldn't stop. (Ended up "building" a
| fancy .MOD player for DOS in Turbo C.)
|
| Needed the Max 5x plan after two hours. (The 'Pro' plan should be
| renamed 'Sampler', made one-time and free with CC details.) Max
| 5x seems like it can sustain my current appetite.
|
| I very quickly went from thinking it was overpriced (around 100
| USD/month) to worrying that this pricing can't last. I think I
| get about 50 working hours per week with this plan. So, running
| the numbers I guess the hourly cost is about 50 cents.
| cloudking wrote:
| /sandbox https://code.claude.com/docs/en/sandboxing
| e12e wrote:
| > The sandboxed bash tool uses OS-level primitives to enforce
| both filesystem and network isolation.
|
| As I can't trust Claude Code to use a correct shell, I don't
| know why I would trust this feature.
| azuanrb wrote:
| Note that there are reports that it can disable sandbox, so
| personally I wouldn't trust this.
| linkregister wrote:
| From within VSCode, you can run devcontainers, which bind
| mounts the project's directory into an isolated Docker
| container. Safe for --dangerously-skip-permissions
|
| https://code.visualstudio.com/docs/devcontainers/containers
| mbreese wrote:
| As a note, running devcontainers in VSCode is easy, but not
| required. There is also a CLI tool that uses the same
| specifications.
|
| You can install it with brew or npm.
| pwagland wrote:
| I assume that you are talking about the [devcontainers
| LCI](https://github.com/devcontainers/cli) when you say "a
| CLI"?
| mbreese wrote:
| Yes. I probably should have included the link.
|
| I stated using devcontainers through VSCode and find them
| incredibly helpful. It's great for me to be able to load
| up exact coding environments on different computers. But,
| I only used them through VSCode.
|
| When I wanted to branch out a bit (and especially using
| coding agents), I started using the CLI version more. I
| find devcontainers a great way to work with different
| coding projects and wanted to make sure people knew that
| there was a way to use them outside of VSCode.
| bugglebeetle wrote:
| Tried this the other day and the setup on this is super
| cumbersome and requires you to constantly rebuild your entire
| dev and Claude Code environment every time you use a new
| container, including whitelisting URLs for package managers
| and the like.
| andrewmutz wrote:
| There are techniques to mitigate this. You can reuse
| containers instead of creating a new one each time. You can
| mount in directories (like ~/.claude) from your local
| machine so you dont have to set claude up each time.
| raphinou wrote:
| I use agents in a container and persist their config like
| you suggest. After seeing some interest I shared my setup
| at https://github.com/asfaload/agents_container It works
| fine for me on Linux.
| giancarlostoro wrote:
| I mean, it depends on what you're doing but I force claude to
| always commit code every time it finishes a todo. It never
| seems to stop doing that, so I run it in dangerous mode on Zed.
| I get to review the code after the fact anyway.
| pluralmonad wrote:
| The danger there is not that it commit bad things, but that
| as part of working the task it gets tricked into sending your
| env/secrets/credentials to prompt injectors. That would not
| show up in your commit diff.
|
| Edit: At the very least, I would not allow it to do
| indiscriminate web searching.
| Someone wrote:
| The risk isn't that it makes weird commits; it's that it may
| decide to clean up stuff and delete more than desired.
|
| - https://github.com/anthropics/claude-code/issues/4331
|
| - https://github.com/anthropics/claude-code/issues/7787
|
| - https://news.ycombinator.com/item?id=46268222
| bs7280 wrote:
| Simon Willison just posted about using claude in fly.io's dev
| sandboxes. I have not tried it yet but it looks promising.
|
| https://simonw.substack.com/p/first-impressions-of-claude-co...
| greggh wrote:
| Use a devcontainer. Claude Code's repo has one built
| specifically for it:
|
| https://github.com/anthropics/claude-code/tree/main/.devcont...
| avsm wrote:
| The Claude Code devcontainer works really well, especially
| the firewalling script! I had do a bit of GitHub Actions
| spelunking to figure out how to build binary images (with my
| own devtools preinstalled), which I wrote up here:
| https://anil.recoil.org/notes/ocaml-claude-dev
|
| With this I have a nice loop where I get Claude to analyse
| its own sessions via a cronjob and rewrite my devcontainer
| Dockerfile to have any packages that I've started using
| during the interactive sessions. This rebuilds via GHActions
| and my fresh image the next day has an updated Claude and dev
| environment in a sandbox.
| jmacd wrote:
| Docker desktop has a pretty nice sandbox feature that will also
| store your CC (and other) credentials, so you don't have to re-
| auth every time you create a new container.
| avsm wrote:
| Funnily enough, we shipped the Docker Desktop VM a decade ago
| now (experience report at
| https://dl.acm.org/doi/10.1145/3747525). The embedded VM in
| DD is much more stripped down than the one in Claude Cowork
| (its based on https://github.com/linuxkit/linuxkit), and its
| more specialised to container workloads rather than just
| using bubblewrap for sandboxing (system services run in their
| own isolated namespaces).
|
| Given how many products seem to be using this shipping-Linux-
| as-a-library-VM trick these days, it's probably a good time
| for an open source project to step up to supply a more
| reusable way of assembling this layer into a proper Mac
| library...
| realityfactchex wrote:
| Isn't the easy way just a development VM? As in:
|
| Install your OS of choice in a virtual machine, e.g. even
| hosted on your main machine.
|
| Install the AI coding tool in the virtual machine.
|
| Set up a shared folder between host+guest OS.
|
| Only let the VM access files that are "safe" for it to access.
| Its own repo, in its own folder.
|
| If you want to give the AI tool and VM internet access and tool
| access, just limit what it can reach to things it is allowed to
| go haywire on. All the internet and all OS tools are ok. But
| don't let this AI do "real things" on "real platforms" -- limit
| the scope of what it "works on" to development assets.
|
| When deploying to staging or prod, copy/sync files out of the
| shared folder that the AI develops on, and run them. But check
| them first for subterfuge.
|
| So, don't give the AI access to "prod"
| configs/files/services/secrets, or general personal/work data,
| etc. Manage those in other "folders" entirely, not accessible
| by the development VM at all.
|
| Is that close?
| c0balt wrote:
| Automating this setup is also somewhat easily possible with,
| e. G., Lima[0] or HashiCorp vagrant[1].
|
| [0]: https://lima-vm.io/
|
| [1]: https://developer.hashicorp.com/vagrant
| w0m wrote:
| I'd just do it over a Docker mount (or equivalent) to keep it
| a bit more lightweight. Can keep the LLM running local; and
| teach it how to test/debug via instruction files.
| aprilnya wrote:
| Claude Code on web is okay in the meantime if you want to set
| it loose but not on your own machine.
| sirmoveon wrote:
| Maybe not easy or for everyone but you can set a Virtualbox VM
| running a headless linux of your choice, install directory
| sharing like samba and your AI agents of choice. Then you can
| just have multiple SSH sessions to interact with the agents and
| `tail` logs.
| colechristensen wrote:
| I built something to use for myself which is organized
| workspaces to work on many things with Claude in parallel with
| the ability to run things in VMs and linked web browsers all
| contained in one app. I built it mostly driven by trying to
| work on too many things at once and getting lost in a sea of
| windows and browser tabs.
|
| It is not at all ready for public consumption (a face only a
| mother could love, in other words it's a bugridden mess), but
| I've considered polishing it and releasing it to the public
| either as open source or for profit.
|
| Most of it is written with Claude and I've run into roadblocks
| with Claude being able to do too many things at once and am
| rewriting as several libraries to improve the focus for Claude
| agents.
| Jayakumark wrote:
| How about the windows App ?
| dijit wrote:
| Is that even a sandbox?
|
| I thought it was just a wrapper around an (old) existing tool
| that has been infinitely rebranded. Their old "remote desktop"
| program and some web listing capabilities to launch it in
| "rootless" mode.
___________________________________________________________________
(page generated 2026-01-15 23:00 UTC)