felixrieseberg

Thank you! I'll fix both of these pronto

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.

Worth calling out that execution runs in a full virtual machine with only user-selected folders mounted in. CC itself runs, if the user set network rules, with https://github.com/anthropic-experimental/sandbox-runtime.

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

Oh, to be clear, I have a team of amazing humans and Claude working with me!

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.

Hey Neil, this is cool! If you package it up as a desktop extension (https://github.com/anthropics/dxt) and send it to me (https://docs.google.com/forms/d/e/1FAIpQLScHtjkiCNjpqnWtFLIQ...), I'd add it to Claude's directory of local MCP servers!

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.

Ah, shoot, I had an error in my build script. That's now fixed!

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

Yeah, reproducible builds would be fantastic.

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.

Daniel, congrats! I'm _so_ excited about everything y'all have achieved in the last few years.

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.

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

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 (fr@makenotion.com) 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.

It sounds like you're looking for CSS frameworks and plenty of them exist - Bootstrap for instance doesn't require you to use the JS part of it.

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.

I like 1Password's secure starter kit: https://github.com/1Password/electron-secure-defaults

It's a common test to ensure you're truly comfortable with your decisions and actions: If a major newspaper would describe your actions or quote you directly on their front page tomorrow, would you still stand behind those words and actions?

The "test" is much older than Stripe but we often use it as a shorthand to ask ourselves whether we truly think a certain course of action is the right one.

You seem to misunderstand the original request _and_ the proposal. We so far only have the CCC's request, no further details are known.

If you go by the proposal, FOSS and Open Source is out of scope. In the case of Log4j, companies knowingly selling software that contains in insecure version of Log4j now need to own that defect.

Before you pick up pitchforks, it's important to understand that this has been requested by the reputable Chaos Computer Club for years.

It's targeted at commercial proprietary software with disclosed and unfixed vulnerabilities. In other words, if you're knowingly selling software that materially harms your users, you're on the hook.

As an example: You're buying "Foo Professional" from MegaCorp. It contains an insecure version of Log4j. You're paying MegaCorp $500,000 per year for license fees. MegaCorp refuses to patch the used version of Log4j. With this proposal, you now have a legal basis for arguing that you _deserve_ a fixed version of "Foo Professional" unless MegaCorp told you clearly by which date "Foo Professional" expired.

I think that's a sensible way to think about it.

It's cute. Well done!

James Friend is the one who got the C compiled with Emscripten, and as long as you're able to serve an entire disk image from a server (and don't crumble under the bandwidth), a browser is good enough.

Electron is only here to ensure that state is saved (save a game, quit the app, start the app, your save game is still there) and to make the mounting of disk images and transfer of files from your local machine super easy.

It's worth a try ;-)

https://www.macintoshrepository.org/195-microsoft-excel-1-03...

Developer here! I'm so excited to see that people like this toy. I'm happy to answer any questions, if you have any.

But first, some important credits: Emulator: Basilisk II, a 68k Macintosh emulator, by Christian Bauer et al, modified and compiled with Emscripten by James Friend. Installed software from vintage computing archives: WinWorldPC, Macintosh Garden, and Macintosh Repository.

Author here. You're 100% right, I do consider Basilisk and the Emscripten compiler to be the "real" work here. I added that in a Credits file in the repo, the app, and even _in_ the virtual machine - because I think that's important to know.

Hi, author here! This is silly, but I'm allocating the entire size of the _virtual_ disk on your actual hard drive. There's probably a smarter way to do this, but that's how it is right now. PRs would be lovely!

Fun fact: The Chromium dev tools are "just another web app": https://github.com/ChromeDevTools/devtools-frontend