161–170 of 201 posts
It's incredible how many applications abuse disk access. In a similar fashion, Apple Podcasts app decided to download 120GB of podcasts for random reason and never deleted them. It even showed up as "System Data" and made me look for external drive solutions.
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 pro…
It would be really nice to have an option to not do this since a ton of companies deny VMs in their group policies.
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.
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 pro…
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.”
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 pro…
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.
This GitHub issue itself is clearly AI slop. If you’ve been dealing with GitHub issues in the past months it will be obvious, but it’s confirmed at the end: > Filed via Claude Code I assume part of it is true, but determining which part is true is the hard part. I’ve lost a lot of time chasing AI-written bug reports that were actually something else wrong with the user’s computer. I’m assuming the claims of “75% fast…
If your codebase is entirely vibe coded, I feel it only appropriate to permit issues being vibed as well. It's hypocritical otherwise.
Earlier quoted context omitted.
I think these are are excellent points, but the complaint talks about significant performance and power issues.
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.
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
Earlier quoted context omitted.
The system data issue on macOS is awful. I use my MacBook for a mix of dev work and music production and between docker, music libraries, update caches and the like it’s not weird for me to have to go for a fresh install once every year or two. Once that gets filled up, it’s pretty much impossible to understand where the giant block of memory is.
The trick is to reboot into recovery partition, disable SIP, then run OmniDiskSweeper as root (as in `sudo /Applications/OmniDiskSweeper.app/Contents/MacOS/OmniDiskSweeper`). Then you can find all kinds of caches that are otherwise hidden by SIP.
Earlier quoted context omitted.
Agreed, it should work like the iCloud Photos library; cache locally, but pull from the cloud when necessary.
Even with the way Photos work - which is desirable, I agree - I should be able to specify a limit on how much local disk it uses. I don't know what the formula it uses is, but it's insufficient.
Note that if your Photos library is already larger than you want it to be, you may need to make sure it's synced, delete it, and create a new library on the drive. It will then sync with iCloud. But that's a hassle, and I would back up the library before you do this.
Earlier quoted context omitted.
Yep, it is an awful situation. I'm increasingly becoming frustrated with how Apple keeps disrespecting users. I downloaded several MacOS installers, not for the MacBook I use, but intending to use them to create a partitioned USB installer (they were for macOS versions that I could clearly not even use for my current MacBook). Then, after creating the USB, since I was short of space, I deleted the installers, includi…
Disk utility lets you delete them.