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

[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?

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

[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?

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

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

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

[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

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

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

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

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