Comments URL: https://news.ycombinator.com/item?id=48995671

Points: 17

# Comments: 3

Comments URL: https://news.ycombinator.com/item?id=48416257

Points: 3

# Comments: 1

Comments URL: https://news.ycombinator.com/item?id=47801011

Points: 1

# Comments: 0

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!

All technology choices are about trade-offs, and while our desktop app does actually include a decent amount of Rust, Swift, and Go, but I understand the question - it comes up a lot. Why use web technologies at all? And why ship your own engine? I've written a long-form version of answers to those questions here: https://www.electronjs.org/docs/latest/why-electron

To us, Electron is just a tool. We co-maintain it with a bunch of excellent other people but we're not precious about it - we might choose something different in the future.

There is much more to do - and our docs reflect how early this is - but we're investing in making progress towards something that's "safe".

(We're also battling an unrelated Opus 4.5 inference incident right now, so you might not see Cowork in your client right away.)

I also think this is pretty big. I think a problem we collectively have right now is that getting MCP closer to real user flows is pretty hard and requires a lot of handholding. Ideally, most users of MCP wouldn't even know that MCP is a thing - the same way your average user of the web has no idea about DNS/HTTP/WebSockets. They just know that the browser helps them look at puppy pictures, connect with friends, or get some work done.

I think this is a meaningful step in the direction of getting more people who'll never know or care about MCP to get value out of MCP.

Comments URL: https://news.ycombinator.com/item?id=45416515

Points: 1

# Comments: 0

As a hiring manager, my inbox is already drowning. I don't mind the applications, I mind that most of them are _clearly_ not a good fit to the point where I'm confident that they themselves have not looked at the job posting for a single second.

The more tools like yours will be built, the more you'll have to know someone who knows me to even get a chat with me - because I won't browse through hundreds of automated messages just to find the one that isn't. I'll be honest: That'll create a tech world even more hostile to people without "the right connections" - and that makes me sad.

https://github.com/felixrieseberg/clippy/releases/tag/v0.4.1

I sign my binaries on macOS with Apple codesign and notarize - and with Microsoft's Azure trusted signing for Windows. Both operating systems will actually show you a lot of warning dialogs before running anything unsigned. It's far from perfect - but I do wish we'd get more into the habit of signing binaries, even if open source.

In general, pruning libraries in Electron isn't as easy as it should be - it's probably something for us to work on.

Comments URL: https://news.ycombinator.com/item?id=43905942

Points: 1122

# Comments: 275

I wrote @electron/windows-sign specifically to cover it: https://github.com/electron/windows-sign

Reference implementation: https://github.com/felixrieseberg/windows95/blob/master/forg...