[felixrieseberg]

Hi, Felix from Anthropic here. I work on Claude Cowork and Claude Code.

Claude Cowork uses the Claude Code agent harness running inside a Linux VM (with additional sandboxing, network controls, and filesystem mounts). We run that through Apple's virtualization framework or Microsoft's Host Compute System. This buys us three things we like a lot:

(1) A computer for Claude to write software in, because so many user problems can be solved really well by first writing custom-tailored scripts against whatever task you throw at it. We'd like that computer to not be _your_ computer so that Claude is free to configure it in the moment.

(2) Hard guarantees at the boundary: Other sandboxing solutions exist, but for a few reasons, none of them satisfy as much and allow us to make similarly sound guarantees about what Claude will be able to do and not to.

(3) As a product of 1+2, more safety for non-technical users. If you're reading this, you're probably equipped to evaluate whether or not a particular script or command is safe to run - but most humans aren't, and even the ones who are so often experience "approval fatigue". Not having to ask for approval is valuable.

It's a real trade-off though and I'm thankful for any feedback, including this one. We're reading all the comments and have some ideas on how to maybe make this better - for people who don't want to use Cowork at all, who don't want it inside a VM, or who just want a little bit more control. Thank you!

[baconner]

FWIW I think many of us would actually very much love to have an official (or semi official) Claude sandboxing container image base / vm base. I wonder if you all have considered making something like the cowork vm available for that?

[hedgehog]

There is this:

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

It does work but I found pretty quickly that I wanted to base my robot sandbox on an image tailored for the project and not the other way around.

[baconner]

Ok I'd seen some sample sandbox scripts for this from anthropic before but not a full reference container. nice, thank you for sharing.

[beklein]

Perhaps useful, I discovered: https://github.com/agent-infra/sandbox

> All-in-One Sandbox for AI Agents that combines Browser, Shell, File, MCP and VSCode Server in a single Docker container.

[parliament32]

This? https://code.claude.com/docs/en/devcontainer

[swyx]

what would you use it for?

[skoocda]

Not OP, but having the exact VM spec your agent runs on is useful for testing. I want to make sure my code works perfectly on any ephemeral environments an agent uses for tasks, because otherwise the agent might invent some sort of degenerate build and then review against that. Seen it happen many times on Codex web.

[baconner]

What the other poster here said for testing against a reference, but also as an easier to get started with base for my own coding sandbox with coding agents. Took me quite a while to build one on my own that I was semi-happy with but I'd imagine one solid enough to run cowork on safely might have some deeper thinking and review behind it.

[deaux]

> It's a real trade-off though and I'm thankful for any feedback, including this one.

Feedback: If your app is going to use 10GB of storage, tell the user in advance and give them a one-click way to remove it. Just basic manners. Don't pick your nose at the dinner table. It's not hard, just common decency.

> even the ones who are so often experience "approval fatigue". Not having to ask for approval is valuable.

This is by and large a short-term pro for Anthropic. It's often not one for the user, and in the long-term, often barely even for the company. In any case, it's a great example of putting Anthropic priorities above the users'. Which is fine and happens all the time, but in this case just isn't necessary. Similar to the AGENTS.md case. We're on the cusp of a pattern establishing here and that's something you'll want to stop before it's ossified.

[kartika848484]

agree to this if their target market is only developers

but over 90% of their users are non technical so removing that approval step is the correct move in a product sense.

users install cowork for the magic, 10gb is negligible. these days even steam games are 50gb+ and you care more about the gameplay than the disk space.

hn should really touch more grass.

[beej71]

I think these are are excellent points, but the complaint talks about significant performance and power issues.

[wutwutwat]

That's every virtual machine that's ever existed. They are slower than metal and you're running two OS stacks so you'll draw more power.

[binsquare]

Not every virtual machine, try microVMs.

I am building one now that works locally. But back in the day, I saw how extremely efficient VMs can be at AWS. microVMs power lambda btw

[bobmcnamara]

Hot forking would be a killer app here - far faster to clone a VM, screw it up, burn it down, and repeat than anything else

[quinncom]

I accidentally clicked the Claude Cowork button inside the Claude desktop app. I never used it. I didn't notice anything at the time, but a week later I discovered the huge VM file on my disk.

It would be really nice to ask the user, “Are you sure you want to use Cowork, it will download and install a huge VM on your disk.”

[divan]

Same. I work on M3 Pro with 512GB disk, and most of the time I have aroung 50GB free that goes down to 1GB often quite quick (I work with video editing and photos and caches are agressive there). I use apps like Pretty Clean and some own scripts (for brew clean, deleting Flutter builds, etc). So every 10GB used is a big deal for me.

Also discovered that VM image eating 10GB for no reason. I have Claude Desktop installed, but almost never use it (mostly Claude Code).

[ephou7]

Jesus Christ what kind of potatos are you using when 10 GB of disk space are even noticable for you?

[quinncom]

If I had been tethering to mobile hotspot at the time it would have instantly used 500 pesos of data. That’s 3x my monthly electric bill.

[wredcoll]

Must be an apple thing

[radicality]

I tried to use it right after launch from within Claude Desktop, on a Mac VM running within UTM, and got cryptoc messages about Apple virtualization framework.

That made me realize it wants to also run a Apple virtualization VM but can’t since it’s inside one already - imo the error messaging here could be better, or considering that it already is in a VM, it could perhaps bypass the vm altogether. Because right now I still never got to try cowork because of this error.

[lxgr]

Does UTM/Apple's framework not allow nested virtualization? If I remember correctly from x86(_64) times, this is a thing that sometimes needs to be manually enabled.

[thomascountz]

I've come across two different answers regarding Apple's Virtualization.Framework support for nested virtualization:

1. Yes, but only Linux guests 2. Yes, but only M3+

https://github.com/apple/container/issues/191

[PrairieFire]

You are correct on both accounts, as of tahoe 26.3 you can't nest a macOS guest under a macOS guest. However you can nest 2 layers deep with any combo of layer 1 guest so long as the machine is running Sequoia and is M3/M4/M5.

[blcknight]

I would look at how podman for Mac manages this; it is more transparent about what's happening and why it needs a VM. It also lets you control more about how the VM is executed.

[exabrial]

Felix, is there any way you guys could fix this simple, but absolutely terribly annoying bug?

Claude mangles XML files with <name> as an XML Tag to <n>

https://news.ycombinator.com/item?id=47113548

[rvz]

> (2) Hard guarantees at the boundary: Other sandboxing solutions exist, but for a few reasons, none of them satisfy as much and allow us to make similarly sound guarantees about what Claude will be able to do and not to.

This is the most interesting requirement.

So all the sandbox solutions that were recently developed all over GitHub, fell short of your expectations?

This is half surprising since many people were using AI to solve the sandboxing issue have claimed to have done so over several months and the best we have is Apple containers.

What were the few reasons? Surely there has to be some strict requirement for that everyone else is missing.

But still having a 10 GB claude.vmbundle doesn't make any sense.

[aberoham]

Claude Cowork grabs local DNS resolution on macOS which conflicts with secure web gateway aka ZTNA aka SASE products such as Cloudflare Warp which do similar. The work-around is to close Cowork, let Warp grab mDNSResponder's attention first, then restart Claude Desktop, or some similar special ordering sequence. It's annoying, but you could say that about everything having to do with MITM middleboxes.

[ukuina]

Can you allow placing the VM on an external disk?

Also, please allow Cowork to work on directories outside the homedir!

[lxgr]

I suppose you could just symlink the directory it's in?

[bachittle]

Do you think it would be possible in the future to maybe add developer settings to enable or disable certain features, or to switch to other sandboxing methods that are more lightweight like Apple seatbelt for example?

[flatline]

There's a lot that's not being said in (2). That warrants more extensive justification, especially with the issues presented in the parent post.

[Someone1234]

They're using the harnesses provided by the respective underlying Operating Systems to do virtualization.

I'd like to explore that topic more too, but I feel like the context of "we deferred to MacOS/Windows" is highly relevant context here. I'd even argue that should be the default position and that "extensive justification" is required to NOT do that.

[Fraaaank]

I wasn't aware that this VM was created. If this was communicated in the marketing I probably would've started using cowork sooner.

[tyfon]

It would be really nice to have an option to not do this since a ton of companies deny VMs in their group policies.

[Terretta]

To a firm with such policies, to allow Cowork outside the VM should be strictly worse.

Ironically, VMs are typically blocked because the infosec team isn't sure how to look inside them and watch you, unlike containers where whatever's running is right there in the `ps` list.

They don't look inside the JVM or .exes either, but they don't think about that the same way. If they treat an app like an exe like a VM, and the VM is as bounded as an app or an exe, with what's inside staying inside, they can get over concerns. (If not, build them a VM with their sensors inside it as well, and move on.)

This conversation can take a while, and several packs of whiteboard markers.

[lrakster]

Agreed. Need to make this a choice for us.

[Terretta]

> real trade-off … thankful for any feedback

Speaking as a tiny but regulated SMB that's dabbling in skill plugins with Cowork: we strongly appreciate and support this stance. We hope you don't relax your standards, and need you not to. We strongly agree with (1), (2), and (3).

If working outside the sandbox becomes available, Cowork becomes a more interesting exfil vector. A vbox should also be able to be made non-optional — even if MDM allows users to elevate privileges.

We've noticed you're making other interesting infosec tradeoffs too. Your M365 connector aggressively avoids enumeration, which we figured was intentional as a seatbelt for keeping looky-loos in their lane.* Caring about foot-guns goes a long way in giving a sense of you being responsible. Makes it feel less irresponsible to wade in.

In the 'thankful for feedback' spirit, here's a concrete UX gap: we agree approval fatigue matters, and we appreciate your team working to minimize prompts.

But the converse is, when a user rejects a prompt — or it ends up behind a window — there's no clear way to re-trigger. Claude app can silently fail or run forever when it can't spin up the workspace, wasn't allowed to install Python, or was told it can't read M365 data.

Employees who've paid attention to their cyber training (reasonably!) click "No" and then they're stuck without diagnostics or breadcrumbs.

For a CLI example of this done well, see `m365-cli`'s `auth` and `doctor` commands. The tool supports both interactive and script modes through config (backed by a setup wizard):

https://pnp.github.io/cli-microsoft365/cmd/cli/cli-doctor/

Similarly, first party MCPs may run but be invisible to Cowork. Show it its own logs and it says "OK, yes, that works but I still can't see it, maybe just copy and paste your context for now." A doctor tool could send the user to a help page or tell them how to reinstall.

Minimal diagnostics for managed machines — running without local admin but able to be elevated if needed — would go a long way for the SMBs that want to deploy this responsibly.

Maybe a resync perms button or Settings or Help Menu item that calls cowork's own doctor cli when invoked?

---

* When given IDs, the connector can read anything the user can anyway. We're able to do everything we need, just had to ship ID signposts in our skill plugin that taps your connector. Preferred that hack over a third party MCP or CLI, thanks to the responsibility you look to be iteratively improving.

[xvector]

Cowork has been an insane productivity boost, it is actually amazing. Thank you!

[consumer451]

Any chance you guys could get the Claude Desktop installer fixed on Windows? It currently requires users to turn on "developer mode."

Sorry for the ask here, but unaware of other avenues of support as the tickets on the Claude Code repo keep getting closed, as it is not a CC issue.

https://github.com/anthropics/claude-code/issues/26457https:...