Migrate Claude Cowork from Electron to Electrobun
Status Fixed / completed
Maintainer reply None cached
Activity 13 comments · opened Feb 18, 2026 · closed Feb 19, 2026
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
Today with Electron
I downloaded Claude Cowork Desktop today.
- The DMG is 241.6MB
- Once I put it in the /Applications folder the app is 574.9MB
- If you're using differential updates, Electron's uses bucket hashes such that a single character change in the beginning of a file affects the bucket position and hashes of the rest of the file, so all your users have to redownload the whole 250MB.
- Electron's
<webview>tag has been deprecated for a year - You're using node.js which is slow when you just acquired Bun
- You have to wait for Electron to update Chromium even with urgent security issues
Tomorrow With Electrobun
- Your DMG could be as small as 14MB, most of that is the bun runtime using electrobun's Zstd bundles
- Built-in differential updates using a custom optimized zig-bsdiff that generates patch files as small as 4KB so you can ship as often as the web without you or your users paying the bandwidth tax
- You can choose to use the system webview or bundleCEF and change the CEF version whenever you want. In the future ladybird and Servo will be drop in alternatives when they're ready.
- Our
<electrobun-webview>tag is re-implemented from the ground up and webview agnostic - When bundling CEF your app can open both Webkit and Chromium webviews and OOPIFs side-by-side
- Our OOPIFs are actually isolated, no dangerous node integration, with encrypted-per-webview, fully typed RPC that is fast
- The Electrobun cli handles bundling, code signing, and notarization for you, just provide the ENV vars.
- Electrobun has built in Update api and generates artifacts that can be put on any static file host (R2, S3, Github Releases)
- Every feature you ship to Bun's runtime, you get in Electrobun.
Why now
- Electrobun just passed v1 (stable architecture) a week ago
- Developers are already shipping production apps with Electrobun
- It is gaining over 1,000 github stars per day
- It is a next-gen desktop app framework
- developers just write typescript for both the main and browser processes so you can move fast and share code.
The Next Steps
Right now, you are shipping a heavy, slow Node.js/Electron environment to your users literally weeks after acquiring the fastest JavaScript runtime on the planet.
I’d love to help the Anthropic team fix this. I see two paths forward:
- The Migration: I am happy to prioritize whatever specific APIs the Claude Desktop team needs in Electrobun over the next sprint to make a 14MB footprint a reality.
- The Status Quo: You stick with Electron, and keep paying the massive bandwidth tax and UX penalty of shipping Chromium and Node when you already own Bun.
References
Claude now:
<img width="283" height="563" alt="Image" src="https://github.com/user-attachments/assets/77125d25-d499-4017-913d-cbf0d98d6793" />
Electrobun v1:
https://x.com/YoavCodes/status/2020348890525155621?s=20
https://github.com/blackboardsh/electrobun
<img width="1176" height="741" alt="Image" src="https://github.com/user-attachments/assets/e6d90427-0200-47f6-9a62-c9108cdccb68" />
Video Demos
- Co(lab): a hybrid web browser, code editor, and PTY terminal for deep work. https://youtu.be/WWTCqGmE86w
- Audio TTS: a vibe coded app I built with Claude Code in Colab using Electrobun, the audio for both videos generated using it. https://youtu.be/Z4dNK1d6l6E
Proposed Solution
Migrate to Electrobun.
Alternative Solutions
_No response_
Priority
Critical - Blocking my work
Feature Category
Performance and speed
Use Case Example
_No response_
Additional Context
_No response_
13 Comments
+1
the desktop is already pretty bad, let's at least make it faster and smaller
+1
huge +1. i'm building a commercial app with electrobun. its a breeze
Please
+1
100% agree
Very supportive
Why not migrate to Tauri?
+1
+1
Thanks for the suggestion! I'm going to close this issue for now as we have no plans to migrate - but if you're curious about some of the choices we made (and why, for instance, we chose to ship our own rendering engine), you can check out https://www.electronjs.org/docs/latest/why-electron, where I documented the reasons behind some of them.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.