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!
Hi, Felix here - I'm responsible for said Electron app, including Claude Code Desktop and Claude Cowork.
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.
Hi, Felix from the team here, this is my product - let us know what you think. We're on purpose releasing this very early, we expect to rapidly iterate on it.
(We're also battling an unrelated Opus 4.5 inference incident right now, so you might not see Cowork in your client right away.)
Disclosure: I work at Anthropic, have worked on MCP
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.
> Instead of competing with hundreds in the application pile, you reach decision-makers directly.
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.
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.
The real answer is that some of us (the Electron maintainers) have been playing with local LLMs in desktop apps and right now, node-llama-cpp is by far the easiest way to experiment - but it's also not meant for desktop apps and hence has _a lot_ of dependencies.
In general, pruning libraries in Electron isn't as easy as it should be - it's probably something for us to work on.
Azure Trusted Signing is one of the best things Microsoft has done for app developers last year, I'm really happy with it. It's $9.99/month and open both to companies and individuals who can verify their identity (it used to only be companies). You really just call signtool.exe with a custom dll.
As an Electron maintainer, I'll re-iterate a warning I've told many people before: Your auto-updater and the underlying code-signing and notarization mechanisms are sacred. The recovery mechanisms for the entire system are extremely painful and often require embarrassing emails to customers. A compromised code-sign certificate is close to the top of my personal nightmares.
Dave and toDesktop have build a product that serves many people really well, but I'd encourage everyone building desktop software (no matter how, with or without toDesktop!) to really understand everything involved in compiling, signing, and releasing your builds. In my projects, I often make an argument against too much abstraction and long dependency chain in those processes.
If you're an Electron developer (like the apps mentioned), I recommend:
* Build with Electron Forge, which is maintained by Electron and uses @electron/windows-sign and @electron/osx-sign directly. No magic.
* For Windows signing, use Azure Trusted Signing, which signs just-in-time. That's relatively new and offers some additional recovery mechanisms in the worst case.
* You probably want to rotate your certificates if you ever gave anyone else access.
* Lastly, you should probably be the only one with the keys to your update server.
Notion (Editor) | Full-Time | NYC or SF | 2x/week in office
We're looking for a fullstack eng (if you lean FE/BE that's cool) who is interested in working on the product OR foundational layer of Notion's editor. You'll have a lot of opportunities to build expertise and ownership, and work on some of Notion's business critical projects (ask engineers working on Performance, Offline, CRDT, Editor quality, and AI editing).
Why does our team exist?
• We're here to build the best editor in the world. In 2025 we're focused on building an editor that's fast, collaborative, and offline
• We're also on a mission to build a healthy, fun, and collaborative team culture (ask us about karaoke, matcha, or our top spots in Japan)
• We own surfaces like CRDT, contentEditable, snapshot pipeline, slash menu, table blocks, etc.
Please feel free to reach out to me ([email protected]) if you're interested! If you'd like to learn about culture and day in the life, anybody in the Editor team would be happy to chat with you. You can find more about us on https://www.notion.com/careers.
> In the vast and ever-evolving landscape of web development, certain projects not only capture the imagination of developers worldwide but also redefine the paradigms of design and functionality.
A bit of feedback: Seeing this amount of non-speak and arrogance in the first sentence of the "getting started" readme has me immediately tune out and put this project aside. If there is anything good here, I won't see it.
I wish the industry had a better answer for deterministically profiling the execution cost of JavaScript. Attempts were made in Chromium by hooking into Linux perf, but that change has since been removed.
If anyone has any tips on how to trace JavaScript (not just profile by time, but deterministically measure the cost of it in CI), I'd love to hear tips!
> Electron does not support encryption or protected file locations by default
Jesus, this article is wrong on so many levels. Electron is fundamentally a way to build cross-platform apps with C, C++, and web technologies. It supports anything the operating system supports.
http://twitter.com/felixrieseberg http://www.felixrieseberg.com