VibeDesk is a free, open-source Windows desktop for Claude Code: several sessions side by side, a coloured dot that tells you which one is waiting for you, permission prompts as one-click cards (on your PC or your phone) and a project "brain" Claude reads and writes over MCP. It runs your own Claude Code CLI – nothing is proxied.
Today 2.0 is out. Two things I want to share: what's in it, and a performance bug that is worth knowing about if you build anything with Electron, backdrop-filter or a WebGL background.
Every open wish is in
Since 1.9 I've only collected feature requests as GitHub issues and shipped them in one bigger release instead of a stream of small ones. All six open requests made it:
- Session wrap-up – when Claude changed files in a turn, you get Claude's summary, every changed file with line counts and a suggested commit message. One click commits.
- Pull requests from the Git window – Claude drafts title and description from your commits; VibeDesk creates the branch, pushes and opens the PR through the GitHub CLI.
- Tray status – a dot in the notification area shows the most urgent session, and approvals can be answered from the tray menu.
- Budget per project – cost or tokens per day or week, with a quiet heads-up at 75 % and 100 %. Claude is never stopped.
- "waiting · 3 min" – how long a session has been waiting, on the session, in the tray and on your phone. (This one came from a comment on my last post here – thank you.)
- Hand-off between sessions – when one session sends another a task, a short summary and the changed files come along. (Also from the comments here.)
Plus: living scenes (Claude writes an interactive wallpaper for you), Gemini CLI and Codex as a beta, your own music from a folder, project templates and a second-screen beta.
The bug: 131 % of a core for a terminal spinner
A user (me, honestly) said: "After running VibeDesk for a while it gets really slow." My first guess was a memory leak. I was wrong.
I measured the installed 1.9 with one Claude Code session working in the terminal. Windows said the GPU process used 131 % of a CPU core and the renderer 30 %. Nothing was leaking: main process ~110 MB, renderer heap ~20 MB, flat. The laptop simply got hot and throttled after a while – that was the "slow after a while".
To find the cause I started a second, isolated instance with Playwright's _electron, a copy of the real settings and its own user-data folder. Then I started a real Claude Code session in it and measured CPU per process with the Windows counters while Claude streamed a long answer. Three things added up:
1. A smooth infinite CSS animation forces 60 fps compositing. The "Claude is working" glow on the terminal was animation: claude-glow 2.8s ease-in-out infinite. It doesn't matter how small or cheap the animated property looks – every frame is a new compositor frame, and every frame re-ran the large backdrop-filter: blur() of the glass windows. With steps(5) the glow changes about twice a second, and the compositor rests in between. (Already fixed in a 2.0 build; it was most of the 131 %.)
2. The WebGL rain kept rendering at 0 % rain. The background shader was throttled to 15–30 fps, but nobody told it that at intensity 0 the image doesn't depend on time. Now rain === 0 means "draw one still frame and stop the loop".
3. backdrop-filter is re-computed whenever anything inside the glass element changes. A terminal that receives ~10 writes per second means ~10 re-blurs per second of a window-sized area at device pixel ratio 2. In energy-saver mode the windows now use a nearly opaque background instead of live blur.
Measured the same way, with a real Claude session working:
| GPU process | Renderer | |
|---|---|---|
| 1.9 | 131 % | 30 % |
| 2.0 (glow fix) | ~26 % | ~14 % |
| + still frame at 0 % rain | ~20 % | ~12 % |
| + no live blur in energy saver | ~11 % | ~11 % |
Two measuring traps that cost me time:
-
app.getAppMetrics()[i].cpu.percentCPUUsagein Electron is divided by the number of logical cores. On my 8-core laptop "16 %" meant 128 % of one core. DiffingGet-ProcessCPU seconds was the honest number. - Chromium stops
requestAnimationFramefor occluded windows. If your test window is behind another one, everything looks free. I had to callsetAlwaysOnTop(true),maximize()andfocus()on the test window.
Try it
Windows 10/11, your own Claude Code plan or API key. The installer isn't signed yet, so SmartScreen will ask – "More info → Run anyway".
- Download and a page per feature: https://fxd-gif.github.io/vibedesk/
- Source (MIT): https://github.com/fxd-gif/vibedesk
- Wishes for the next release: open an issue or 👍 an existing one – the most-wanted ones go into the next release.
Not affiliated with Anthropic.
Top comments (0)