DEV Community: Fred 🍓

My ASCII hero redrew every frame from scratch. Only 55 of 12,198 cells had changed.

Fred 🍓 — Thu, 12 Nov 2026 14:00:00 +0000

Last week I rebuilt the website for my open-source app. The hero is a rain cloud made of characters (.·:;!/?*%$&8#@). It drifts, it rains, and it bends a little around your cursor. Plain Canvas 2D, no WebGL, no library.

I built it with the usual performance tricks. Then I turned each one off and measured. Most of them did less than I thought. The biggest win was one I hadn't built.

How the field works

The canvas is a grid of cells, 9 × 15 CSS pixels each. On a 1920 px wide screen the hero canvas is 1920 × 846, so that's 214 × 57 = 12,198 cells. Most of them are dark sky. About 700 show a character at any moment.

Every frame, each cell asks the scene for a brightness between 0 and 1. For the cloud that's a few soft blobs, value noise on top, a flat underside like a real cumulus, and light from above. Brightness picks a character from a density ramp and one of 12 opacity levels. Rain drops are separate particles that write |, : and . into the cells they pass.

The loop runs at most 30 fps, and only while the hero is on screen and the tab is visible:

const io = new IntersectionObserver(([en]) => {
  visible = en.isIntersecting
  start()
}, { rootMargin: '60px' })
document.addEventListener('visibilitychange', start)

The tricks I built in

1. A glyph atlas. Every character is pre-rendered once into an offscreen canvas, in 12 opacity levels and 2 colours. Drawing a cell is a single drawImage from that atlas instead of fillText with a new fillStyle and globalAlpha each time.

2. Interlacing. The noise field is cached. The cloud moves slowly, so each frame only recomputes every second or third row:

const K = baseFull ? 1 : n > 9000 ? 3 : 2
const ph = frameNo++ % K
for (let y = ph; y < rows; y += K) {
  for (let x = 0; x < cols; x++) base[y * cols + x] = scene.sample(/* ... */)
}

3. A bounding box. Once per frame I compute a rectangle around the cloud. Outside it, a cell skips the noise and only gets the odd dust speck.

4. Cheap cursor effects. The lens and the ripples don't sample the noise again. They read the cached field at a shifted position.

One small bug came with the atlas. My first version showed stray dash-like fragments in the cloud. The fix was to clip every glyph to its own cell while building the atlas, so nothing from one character can end up in the neighbouring cell:

a.save()
a.beginPath()
a.rect(x0, y0, acw, ach)
a.clip()
a.fillText(CHARS[i], x0 + acw / 2, y0 + ach / 2 + 0.5)
a.restore()

At today's font and cell sizes I checked every glyph, and none of them leaves its cell anymore. The clip stays anyway. It costs nothing, and it matters for the trick at the end.

Then I measured

Setup: Playwright driving Chromium 153 (headless, but on the real GPU through ANGLE/D3D11), an Intel Iris Xe laptop, viewport 1920 × 1080, device pixel ratio 1, nobody touching the mouse. Two numbers per run:

JS per frame: I wrapped requestAnimationFrame and timed my own callback (update plus all the drawImage calls).
Whole browser: CPU time of every Chromium process over 10 seconds, as a percentage of one core. That includes the GPU process and the compositor, which the JS timer never sees.

I ran each variant several times, alternating, and the table shows the medians. The laptop's clock moves a lot, so identical runs differed by up to ±30 %. Read the numbers as rough.

Variant	JS per frame	Whole browser
Hero switched off	–	~10 %
Everything on (what's live)	3.5 ms	~49 %
Recompute every row (no interlacing)	5.0 ms	~61 %
No bounding box	3.6 ms	~44 %
`fillText` instead of the atlas	3.0 ms	~40 %

Three things surprised me:

My JavaScript was never the problem. 3.5 ms at 30 fps is about a tenth of a core. With the hero running, the whole browser used about half a core, against ~10 % without it. The rest of the bill was the browser itself: clearing a 1920 × 846 canvas, repainting about 700 glyphs and compositing the result, 30 times a second.
Interlacing helped, the bounding box didn't. Interlacing saved about 1.5 ms per frame. The bounding box was within noise, because the blob test it skips was already cheap.
The atlas didn't beat fillText. In this Chrome, on this laptop, plain fillText was the same or a little cheaper. With only about 700 glyphs per frame there isn't much for an atlas to win, and the advice I had in my head is older than the browser I was testing.

The trick I hadn't built: skip what didn't change

So I counted. Between two frames, how many cells actually show a different character, colour or opacity?

A median of 55 out of 12,198. The cloud drifts so slowly that almost every cell lands on the same glyph and level as last frame. Most of the changes are rain.

And every frame I was clearing the whole canvas and drawing about 700 glyphs to show those 55 changes.

The fix: no full clear anymore. Remember what each cell showed, and only touch the cells whose key changed:

for (let i = 0; i < n; i++) {
  const key = cellKey(i)          // glyph, colour and opacity level, or -1 for empty
  if (key === prev[i]) continue   // same as last frame: leave the pixels alone
  prev[i] = key
  const cx = i % cols, cy = (i - cx) / cols
  ctx.clearRect(cx * acw, cy * ach, acw, ach)
  if (key >= 0) drawCell(key, cx, cy)   // one drawImage from the atlas
}

This is where the atlas and the clip pay off after all. Every glyph lives exactly inside its cell, so clearing and redrawing one cell can never cut a neighbour in half. With fillText, a wide glyph could spill over and leave half a character behind.

Variant	JS per frame	Whole browser
Everything on (what's live)	3.5 ms	~49 %
Redraw only changed cells	2.0 ms	~27 %

The whole browser went from about half a core to about a quarter. The renderer and the GPU process both dropped by about half. The visible result is identical, because every cell ends up with exactly the same pixels.

This version isn't on the live site yet. I wanted the measurement first.

Reduced motion

With prefers-reduced-motion: reduce, the field renders one finished frame (rain already placed) and stops. No loop, no cursor reaction:

const RM = matchMedia('(prefers-reduced-motion: reduce)').matches
// ...
if (RM) {
  still()   // one complete frame, then nothing
  return
}

It's two lines, and nobody who asked for less motion gets a cloud that keeps moving.

What this doesn't prove

One laptop, one Chromium build. Firefox and Safari draw text and images differently, and the atlas-vs-fillText result may well flip there.
Nobody moved the mouse. The lens and the ripples can change hundreds of cells per frame, so while you play with the hero, the redraw trick saves much less.
The JS timer only covers my callback. The real cost was elsewhere, which is the point of the second column.

The short version

Measure the whole browser, not just your requestAnimationFrame callback.
Cache what moves slowly. Interlacing was worth about 1.5 ms per frame here.
Don't assume a glyph atlas beats fillText in a current browser. Measure it.
Count how many cells really change. Mine: 55 out of 12,198. Then stop clearing the whole canvas.
Give reduced motion a still frame, not a slower animation.

The whole engine is one file, a bit over 700 lines, no dependencies: assets/ascii.js (some comments are in German, sorry). You can see it running on the VibeDesk website. VibeDesk is a free, open-source Windows app around Claude Code that I build, and the site is where I tried all this.

If you've built something like this: did a glyph atlas ever beat plain fillText for you? A) yes, clearly B) about the same C) never measured. And which browser?

Starting Claude Code from Node on Windows: 6 things that broke for me

Fred 🍓 — Tue, 10 Nov 2026 14:00:00 +0000

Most Claude Code tooling I read about assumes macOS or Linux. I build a Windows desktop app that starts Claude Code sessions in terminals, writes commit messages with claude -p and runs hooks all day. Here's what went wrong on Windows, in the order I hit it, so you don't have to.

1. `claude` isn't an executable

If you installed Claude Code with npm, claude on Windows is a claude.cmd shim. spawn('claude', ...) fails, and since Node's 2024 security fix (CVE-2024-27980) spawning a .cmd without a shell throws EINVAL on purpose.

What works reliably for me is going through cmd.exe explicitly:

const args = ['/d', '/c', 'claude', '--settings', settingsFile, '--mcp-config', mcpFile]
pty.spawn('cmd.exe', args, { cwd, env })

/d skips any AutoRun commands the user has in the registry, so their shell setup can't interfere.

2. Don't add `/s`, and don't quote the first token

cmd /c has odd rules for quotes. With /s, or when the line starts with a quote, it strips the first and last quote character of the whole command line. A settings path like "C:\Users\Jane Doe\...\settings.json" then loses one of its quotes and splits at the space.

Keep the first token (claude) unquoted and leave out /s. Then cmd leaves the quotes around your paths alone. Users with spaces in their username will thank you.

3. Everything on that command line is an injection point

Once you go through cmd.exe, &, | and friends mean something. Two rules I now follow:

Validate anything that becomes an argument. A session ID for --resume has to match ^[A-Za-z0-9-]{1,64}$, or the app refuses to start it.
Never pass user text as an argument. Commit diffs, PR drafts, notes typed on the phone: they all go to claude -p through stdin. The prompt argument is a fixed sentence like "Follow the instructions in the input."

execFile('cmd.exe', ['/d', '/c', 'claude', '-p', 'Write the commit message as instructed in the input.',
  '--model', 'haiku', '--output-format', 'text'], opts)
// the diff and the instructions are written to the child's stdin

4. Your Electron environment leaks into Claude

The child inherits your whole environment. If ELECTRON_RUN_AS_NODE ends up in your app's environment (for example because it was started from a tool that sets it), every Electron-based program started further down runs as plain Node instead. I delete it before spawning:

const env = { ...process.env, MY_APP_SESSION_ID: id }
delete env.ELECTRON_RUN_AS_NODE

Small bonus trap: Windows already has an environment variable called PROMPT (it's $P$G, the cmd prompt format). If your app reads its own PROMPT variable, it gets that.

5. Hook commands have to survive three shells

A hook command in settings.json can end up running in cmd, Git Bash or PowerShell, depending on the setup. The form that worked everywhere for me:

{ "type": "command", "command": "node \"C:\\path with spaces\\hook-forwarder.js\"" }

The program (node) is unquoted, and only the path is quoted. Quoting the program too breaks in cmd for the same reason as trap 2.

6. Line endings, when Claude edits through scripts

This one isn't about spawning, but it bit me hardest. My repo is LF. Sometimes Claude Code decides to change a file with a small Python script instead of its edit tool. Python's open(path, 'w') on Windows writes CRLF, so a one-line change shows up as a diff of the entire file.

Things that help:

A .gitattributes with * text=auto eol=lf, so Git normalises on commit.
A line in CLAUDE.md: prefer the edit tool, and when a script is needed, open files with newline=''.
Look at git diff --stat before every commit. A 900-line change for a typo is your hint.

Related: backslashes inside bash heredocs and non-ASCII characters in curl -d from Git Bash can arrive mangled. If the content matters, write it to a file first and send the file.

What this doesn't cover

I only use Claude Code installed through npm. The native installer may avoid traps 1 and 2 completely, and newer Claude Code versions run sessions through a background service, which changes how a terminal is attached. Check your own setup before copying any of this.

Question

If you use Claude Code on Windows: how do you run it?

A) PowerShell / Windows Terminal

B) Git Bash

C) WSL

D) inside an editor (VS Code, JetBrains)

And what's the weirdest Windows-only bug you hit with it?

(All of the code above comes from VibeDesk, an open-source Windows desktop for Claude Code, if you want to see it in context.)

Claude Code wrote almost all of my app. My job turned into saying no.

Fred 🍓 — Thu, 05 Nov 2026 14:00:00 +0000

Three weeks ago I started a desktop app. Since then: 169 commits, about 48,000 lines in src/, and I typed very little of it myself. Claude Code did. I steered, tested and, more than anything, said no.

That last part surprised me. I expected the bottleneck to be the model getting things wrong. It wasn't. The bottleneck was me letting too much in.

When code is cheap, everything looks worth building

Here's what nobody warned me about. When a feature costs you a sentence and ten minutes, the question "is this worth building?" quietly stops being asked. Everything is worth building, because nothing costs anything.

So I built everything.

Between October 13 and 19 I shipped 29 releases in 7 days. Version 0.7 to 1.9. Every idea went straight in, every release had something new. It felt amazing. It also made the app loud. New windows popped up on top of the terminal. The dock filled with icons. The first-start screen asked "How much do you want to see?" before people had seen anything at all.

Nothing was broken. It was just too much, and I couldn't see it while I was the one adding things.

The no's that made it better

Looking back through my commits, the changes I'm proudest of are mostly removals or restraint:

"New windows never cover Claude." Every new window now finds free space instead of opening on top of the terminal you're working in. One rule, no new features.
New features go into a "More" menu, not the dock. The dock is for the five things you use every hour.
The "How much do you want to see?" question is gone. You start calm, and you find more when you look for it.
The stats card ("Vibe Wrapped") lost its AI-style gradients and got a calm, printed look instead.
The phone connection lost one of its two tunnel options. Two choices meant two things to explain.
No account, no sign-up, no Discord server. Questions go to GitHub issues.
One bigger tested release at a time instead of 30 a week. Feature freeze a few days before.

None of these needed much code. All of them needed someone to say "no, not like that".

The model is great at "yes"

Claude Code is extremely good at doing what you ask. That's the problem. Ask for a toggle and you get a well-built toggle with tests. It won't tell you that nobody will ever find it between all the other toggles.

So these are the questions I try to ask now, before saying "build it":

Who opens this, and how often?
What does it push off the screen?
Would I notice if it were missing?

If I can't answer the first one with a real person, it waits. Ideas that people actually ask for in GitHub issues (with a 👍) go into the next release. The rest stays an idea.

Taste is the job now

I don't think "AI will replace developers" or "AI is just autocomplete" describes what I'm doing. It feels more like being an editor with an infinitely fast writer. The writer never gets tired and never pushes back. The editor has to.

And editing is hard in a new way. You're not judging whether the code works. Usually it does. You're judging whether it should exist.

What this doesn't prove

This is one solo project with no team, no users to negotiate with and no deadline except my own. In a team, "no" is spread over code review, product people and design. I'm doing all of it alone, so maybe I just feel it more.

Question

If you build with an agent most of the day: what's the hardest part of your job now?

A) checking the code is actually right

B) deciding what to build at all

C) keeping the codebase understandable for future me

D) something else, tell me

And what's the last thing you said no to?

(The app is VibeDesk, a calm desktop for running several Claude Code sessions on Windows. Wishes go in its GitHub issues.)

I was sure it was a memory leak. It was a glowing border using 131 % of a CPU core

Fred 🍓 — Wed, 04 Nov 2026 14:00:00 +0000

My app is an Electron desktop for Claude Code: glass windows with backdrop-filter blur, a WebGL rain background, a few terminals. One day I wrote in my own bug list: "If I leave it running for a while, it gets really slow."

"Slow after a while" sounds like a memory leak. I was so sure that I nearly went looking for one. Then I measured first.

The measurement

One Claude Code session working in a terminal, the app in front. Numbers are CPU time per process, as a percentage of one core:

Version	GPU process	Renderer
installed 1.9	131 %	30 %

Memory was flat. Main process around 110 MB, renderer heap around 20 MB, no growth. No leak.

What actually happened: the laptop (integrated Intel graphics) got hot and throttled after a few minutes. "Slow after a while" was thermals, not memory.

So what was burning a core and a third on the GPU process while I was just watching a terminal?

Suspect 1: the glow

When Claude is working, its window gets a soft, breathing glow:

.gwin.claude-working {
  animation: claude-glow 2.8s ease-in-out infinite;
}
@keyframes claude-glow {
  50% { box-shadow: 0 0 0 1px rgba(159,184,255,.3), 0 0 40px rgba(124,156,255,.26); }
}

Pretty, harmless, right? Not with glass around it.

A smooth infinite animation means the compositor has to produce a new frame 60 times a second. And every new frame recomputes the big backdrop-filter blurs of every glass panel on screen. My rain shader was carefully throttled to 15–30 FPS. One CSS animation quietly overrode that and pushed everything to 60.

Two things surprised me:

Size doesn't matter. An 8-pixel equalizer icon in the dock cost the same as the big window glow. Any animated pixel means a new frame, and the blur gets recomputed.
transform instead of box-shadow didn't help either. The usual "animate only transform and opacity" advice is about layout and paint cost. Here the expensive part was the frame itself.

The fix is one word:

.gwin.claude-working {
  animation: claude-glow 2.8s steps(5) infinite;
}

steps(5) makes the glow breathe in five visible stages instead of a smooth curve. Between the steps nothing changes, so no new frames are produced. At normal viewing distance it still reads as "breathing". I moved every long-running infinite animation to steps(): the waiting dot (which can sit there for hours), the equalizer, a live indicator. Short loading spinners stay smooth, because they disappear after a second.

Suspect 2: the rain that wasn't raining

The WebGL rain has an intensity slider. At 0 % you see a still background. But the shader kept rendering 15–30 frames a second of zero raindrops, because the "paused" flag was never passed down.

Now the frame scheduler returns "no frames" at 0 %:

export function frameInterval(s: FrameState): number | null {
  if (s.paused || (s.rain !== undefined && s.rain <= 0)) return null
  if (s.idle) return 1000 / FPS_IDLE
  return 1000 / (s.saver ? FPS_SAVER : FPS_FOCUS)
}

Suspect 3: every line of terminal output

This one I can't fully fix. A terminal that's streaming output changes pixels all the time, and every change under a glass panel recomputes its blur. For battery mode the glass now turns into plain, nearly opaque panels:

.app.saver .gwin, .app.saver .dock { backdrop-filter: none; background: rgba(13,17,25,.9); }

After

Step	GPU process	Renderer
1.9 (smooth glow)	131 %	30 %
glow on `steps()`	~26 %	~14 %
rain off really means off	~20 %	~12 %
battery saver without live blur	~11 %	~11 %

From 131 % to about 11 %, mostly by deleting frames nobody needed.

How I measured (and two traps)

I started a second, isolated copy with Playwright's _electron, a copy of my real settings and its own user-data folder, so the measurement didn't touch my working setup.
Trap 1: app.getAppMetrics() reports CPU divided by the number of cores. On 8 cores, "16 %" is actually more than a full core. I switched to measuring the difference in CPU seconds per process from the OS.
Trap 2: a hidden or covered Electron window stops requestAnimationFrame. My first measurement showed almost 0 % GPU because the test window was behind another one. Bring it to the front (setAlwaysOnTop, focus) before you measure.

What this doesn't prove

It's one app on one laptop with integrated graphics. On a desktop GPU you'd likely never notice the glow. But if your Electron or web app combines backdrop-filter with any infinite animation, it's worth five minutes with the profiler.

Question

Have you ever chased a "leak" that turned out to be something else? What was it?

A) thermals / throttling

B) a runaway animation or render loop

C) a cache doing its job

D) an actual leak, finally

(The app is VibeDesk, open source, so all of the CSS above is in the repo.)

15 YouTube Shorts, 2,674 views, 1 subscriber: promoting a dev tool without showing my face

Fred 🍓 — Tue, 03 Nov 2026 14:00:00 +0000

I build a free, open-source desktop app on my own. I don't want to show my face or record my voice, so when it was time to find users, YouTube Shorts looked perfect: a screen recording, some music, one line of text on top. No camera.

I made 15 of them in two weeks. Here are the real numbers from YouTube Studio and GitHub, because I think a flop with numbers is more useful than another "how I hit 10k" post.

The numbers (last 28 days)

2,674 Shorts views
70 % swiped away almost immediately
32 likes
+1 subscriber from Shorts. One.
GitHub: 21 unique visitors in 14 days, 5 of them from YouTube
GitHub stars: 0

Roughly 3,000 views turned into about five people looking at the code.

What I tried

Fast and flashy. Quick cuts, zooms, 15 seconds, glowing UI. Between 19 % and 25 % of viewers stayed. When I watched them back, even I couldn't tell what was happening.

Slow and simple. One idea per Short, a big crop of the app instead of the whole window, a text line you can read twice. No retention data yet, but the view count landed exactly where the fast ones did.

A plain "it just does the thing". My best Short was 26 seconds of typing "sort my windows" and watching it happen. 42 % stayed. No effects. Just something you'd want.

What I learned

1. The view count barely depends on the video

Every Short landed between 50 and 370 views. YouTube Studio says my Shorts "usually get 140–220". Fast, slow, funny, technical: same band. As far as I can tell the feed shows each Short to a small test group, and if that group swipes, that's it.

2. The Shorts feed is the wrong room

81 % of the views came from the Shorts feed: people scrolling for fun, not people with the problem my app solves. And even someone who likes it can't click a link in a Short. A like costs them nothing. Installing a Windows app from a GitHub release page costs them a lot.

3. A 75-second video beat all 15 Shorts

My one longer video, a 1:15 teaser, got 332 views. People watched 51 % of it on average, and 80 % of the views came from the YouTube home page, so YouTube showed it to people who watch similar things. It also brought one subscriber, as many as all the Shorts together.

4. One honest post here beat everything

Two weeks ago I wrote a short post here: I kept missing Claude Code's permission prompts, so I built a desktop around it. No polish. It got 15 comments, two feature requests (both shipped in the next release) and real conversations.

My more "useful" technical posts after that got zero or one comment each.

5. The real funnel is after the click

Getting someone to the repo is step one. Then there's a release page, an .exe, and a SmartScreen warning because the installer isn't signed. Every step loses people. I spent hours on video edits and almost no time on that path.

What this doesn't prove

It's one small channel, one niche tool, four weeks. Shorts clearly work for some people. Maybe my hooks were just bad. But "make more Shorts" was the advice I kept hearing, and for a dev tool with no face behind it, it was the most expensive way I found to get almost nobody.

What I'm changing

Two Shorts a week at most, instead of one a day.
Longer, calm videos that answer something people actually search for.
More posts like the first one: a real problem, what I tried, what broke.
A shorter download path: one page, one button, SmartScreen explained before it shows up.

Your turn

If you build something alone: what brought you your first 10 real users?

A) a post somewhere like this

B) Reddit / Hacker News

C) video

D) something I haven't thought of

I'd really like to know, especially the things that looked promising and didn't work.

(The app is VibeDesk, a free Windows desktop for running several Claude Code sessions. But this post is about the numbers, not the app.)

8 rules for Claude Code hooks that never get in Claude's way

Fred 🍓 — Sun, 01 Nov 2026 20:24:46 +0000

My app runs one small Node script on every hook event Claude Code fires. Eleven events, every session, all day. If that script is slow, Claude is slow. If it crashes the wrong way, Claude stops.

After a few weeks of that, these are the rules the script follows. None of them are clever. Each one is there because I broke it once.

1. Exit 0. Always.

Claude Code reads your exit code. Exit 2 blocks the action and hands your stderr to Claude as feedback. Any other non-zero code shows up as a hook error. Neither is what you want when your JSON parse fails or your server is down.

So the script has exactly one way out:

const done = () => process.exit(0)

Missing environment variable: done(). Broken JSON on stdin: done(). Connection refused: done(). The only time a hook should change what Claude does is when you decided it should.

2. Bring your own deadline

Claude Code waits for your hook before it moves on, and the default timeout is generous. Don't rely on it. Set a short timeout in the hook config (I use 5 seconds) and add a hard stop inside the script:

let guard = setTimeout(done, 1500)
guard.unref()

unref() matters: the timer never keeps the process alive on its own, it only cuts it off. The HTTP request to my app gets its own 1.2 s timeout on top. If the app is frozen, the session doesn't notice.

3. stdout is not a log

For some events, whatever you print goes straight into Claude's context. On SessionStart, that's a feature. A stray console.log("got event") there is a few tokens of noise in every session, forever.

For others, stdout is read as a decision. So print only when you mean it. My script forwards the event and writes to stdout only if the app answers with a body, which it does in exactly two cases: context at session start and a permission decision. Nothing else ever reaches stdout.

4. PermissionRequest is the one hook that should wait

Every rule above says "be quick". PermissionRequest is the exception, and it's the most useful hook there is.

It fires the moment Claude shows a permission prompt, and you can answer it from the hook. Keep the hook open until a human decides somewhere else (a card in an app, a phone), then print:

{"hookSpecificOutput":{"hookEventName":"PermissionRequest","decision":{"behavior":"allow"}}}

A deny can carry a message, and Claude reads it as the reason. Printing nothing means "no decision": Claude falls back to the normal prompt in the terminal, so the worst case is the behaviour you had without the hook.

One exception, pointed out in the comments: in sessions that can't show a prompt (claude -p, background subagents in non-interactive mode), PermissionRequest hooks still run, and if no hook returns a decision, the tool call is denied. So if you reuse a forwarder like this in a headless run and the app behind it is down, the silent exit 0 from rule 1 turns into a deny.

For this one event I set the hook timeout to 600 s and the script's own deadline to 595 s, so the script always gives up first and cleanly.

Side note: the Notification hook also tells you Claude is waiting, but the permission notification only arrives after a short idle delay. For "Claude needs me right now", use PermissionRequest.

5. On Windows, quote the path, not the program

The hook command in my settings looks like this:

node "C:\Users\me\AppData\Local\Programs\My App\resources\hook-forwarder.js"

The program is unquoted, the path is quoted. That one line runs the same in cmd, Git Bash and PowerShell. Quote the program too and PowerShell reads the first token as a string instead of a command. Install paths on Windows love spaces, so this is not hypothetical.

Newer Claude Code versions have a cleaner way: give the hook an args array and it runs in exec form, with no shell at all:

{
  "type": "command",
  "command": "node",
  "args": ["C:\\Users\\me\\AppData\\Local\\Programs\\My App\\resources\\hook-forwarder.js"]
}

Each element is one argument exactly as written. On Windows, command has to be a real executable like node.exe; the .cmd shims in node_modules/.bin still need shell form. I haven't switched VibeDesk over yet, because it writes settings for whatever Claude Code version you have installed.

Thanks to @skillselion in the comments for this one and the exception in rule 4.

6. No dependencies, no bundler

The whole forwarder is about 85 lines of plain CommonJS. The only import is http. It runs with the system node, straight from the app's resources folder.

Startup time is paid on every single event. A bundled script that pulls in a framework to send one POST request is a few hundred milliseconds you pay hundreds of times a day.

7. Survive your own restarts

Claude sessions outlive the app that started them. When my app updates and restarts, the port and token in each session's environment are stale.

So when the server answers 403, the script rereads a small endpoint file that the app rewrites on every start, and retries exactly once:

if (res.statusCode === 403) {
  res.resume()
  return again() // reread endpoint.json, try once more, else done()
}

Once, not in a loop. Rule 1 still wins.

8. Stop hooks: check `stop_hook_active`

A Stop hook can answer {"decision":"block","reason":"..."} and Claude keeps going with your reason as its next instruction. I use that once per turn: if Claude changed files but didn't write down what it learned, it gets a short nudge to do that before it finishes.

The input then has stop_hook_active: true. If you see that, never block again. Otherwise you've built a loop where Claude finishes, gets sent back, finishes, gets sent back.

The short version

exit 0, every path
a hard deadline inside the script
stdout only when you mean it
PermissionRequest waits, everything else hurries
quote the path, not the program (or skip the shell with args)
no dependencies
reread your endpoint once after a restart
respect stop_hook_active

All of this comes from VibeDesk, the free, open-source Windows desktop I build for running several Claude Code sessions side by side. The forwarder is a single file if you want to copy it: hook-forwarder.js.

What's the worst hook bug you've run into? I'm collecting them.

VibeDesk 2.0 is out – every feature request shipped, and why 1.9 burned 131 % of a CPU core

Fred 🍓 — Sun, 01 Nov 2026 17:05:45 +0000

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.percentCPUUsage in Electron is divided by the number of logical cores. On my 8-core laptop "16 %" meant 128 % of one core. Diffing Get-Process CPU seconds was the honest number.
Chromium stops requestAnimationFrame for occluded windows. If your test window is behind another one, everything looks free. I had to call setAlwaysOnTop(true), maximize() and focus() 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.

Approve Claude Code permission prompts from anywhere with the PermissionRequest hook

Fred 🍓 — Sun, 25 Oct 2026 14:54:24 +0000

A few days ago I wrote about the desktop I built around Claude Code because I kept missing its permission prompts. In the comments someone asked the question I like most: do you detect "waiting" by reading the terminal, or from hooks?

Hooks. And one hook in particular, PermissionRequest, turned out to be much more useful than I expected. You don't need my app for any of this, so here's how it works and what bit me on the way.

The hook

Claude Code runs your command whenever it is about to show a permission prompt. Your command gets JSON on stdin, roughly:

{
  "hook_event_name": "PermissionRequest",
  "tool_name": "Bash",
  "tool_input": { "command": "npm test" },
  "permission_suggestions": [ ... ]
}

and it can answer on stdout:

{
  "hookSpecificOutput": {
    "hookEventName": "PermissionRequest",
    "decision": { "behavior": "allow" }
  }
}

behavior is allow or deny (a deny can carry a message, which Claude reads and reacts to). If you print nothing, Claude Code just shows its normal prompt. That last part is what makes the hook safe to experiment with: you only decide the cases you're sure about.

A tiny example you can use today

Allow a few harmless commands, block one obviously bad one, stay out of everything else:

// approve.js – PermissionRequest hook
let input = ''
process.stdin.on('data', (c) => (input += c))
process.stdin.on('end', () => {
  let cmd = ''
  try {
    const p = JSON.parse(input)
    if (p.tool_name === 'Bash') cmd = String(p.tool_input?.command ?? '')
  } catch {}

  const reply = (decision) =>
    process.stdout.write(JSON.stringify({ hookSpecificOutput: { hookEventName: 'PermissionRequest', decision } }))

  if (/^(git (status|diff|log)|ls|pwd|npm test)\b/.test(cmd) && !/[;&|>]/.test(cmd)) reply({ behavior: 'allow' })
  else if (/\brm\s+-rf\s+[\/~]/.test(cmd)) reply({ behavior: 'deny', message: 'Not deleting from / or ~. Ask me first.' })
  // anything else: print nothing -> normal prompt
})

And in .claude/settings.json:

{
  "hooks": {
    "PermissionRequest": [
      { "matcher": "Bash", "hooks": [{ "type": "command", "command": "node /path/to/approve.js", "timeout": 10 }] }
    ]
  }
}

(Yes, allow/deny rules in settings cover a lot of this too. The hook gets interesting when the decision needs logic, or a human somewhere else.)

Answering from another window, or your phone

This is the part I actually built it for. The hook doesn't have to answer right away. It can just wait.

In VibeDesk every session gets a settings file that points all hook events to a small forwarder script. For PermissionRequest the forwarder POSTs the JSON to the app on 127.0.0.1 and keeps the request open. The app shows a card with the command and Allow / Always / Deny / In terminal, on the desktop and on a paired phone. Whatever you tap becomes the HTTP response, the forwarder prints it, Claude Code continues. Nothing has to type y into a PTY. (Claude Code still shows its normal prompt in the terminal while the hook waits, so you can answer in either place.)

"Always" sends back the permission_suggestions Claude Code offered as updatedPermissions, so it's the same as picking "don't ask again" in the terminal.

Things that bit me

1. The hook must never break Claude. It runs on every single prompt. If it crashes, hangs or exits with an error, you've made Claude Code worse. My forwarder always exits with code 0, has a hard timer, and if the app isn't running it just exits silently, so Claude falls back to the normal prompt.

2. Timeouts. Claude Code gives a command hook 600 seconds by default, which is plenty for a human. The catch is the other direction: my forwarder runs on every event, so I set all other events to 5 s (a stuck app must never slow Claude down) and only PermissionRequest keeps 600. The script gives up by itself at 595 s, so it always returns before Claude Code kills it. Otherwise you get a confusing state instead of a clean fallback.

3. People answer in the terminal anyway. Sometimes you're already looking at that window and just press enter. Then the card in the app is stale. The fix: when PostToolUse arrives for the same tool and the same input, close the open card. Same for UserPromptSubmit, Stop and SessionEnd.

4. Restarts. After an app update the port and token change, but sessions are still running with the old ones in their environment. The forwarder now re-reads a small endpoint file when it gets a 403 and retries once.

5. Don't parse the terminal. My first version looked for the prompt text in the output. It broke on every small UI change. Hooks are the stable interface, use them.

Detecting "waiting" in general

PermissionRequest tells you a session is blocked on you, and it fires right away. Notification also fires for permission waits, but only after a few seconds (and not always), so don't rely on it for that. Stop tells you a turn is done. With just those three you can drive a status light, a Stream Deck key, a tray icon or a phone notification. That's all the yellow dot in my app really is.

VibeDesk is free and MIT licensed (Windows): https://github.com/fxd-gif/vibedesk. Version 2.0 comes out on Sunday, Nov 1, with session wrap-ups, tray status and sessions that can hand tasks to each other. If you build something with this hook, I'd love to see it in the comments.

And here's the short teaser for 2.0:

I kept missing Claude Code's permission prompts, so I built a desktop around it

Fred 🍓 — Thu, 22 Oct 2026 08:40:29 +0000

I usually have two or three Claude Code sessions open: a frontend, an API, sometimes a side project. And the most annoying thing wasn't the model or the cost. It was this:

One session finishes. Another one is working. And the third one has been sitting there for fifteen minutes, asking "Do you want to run npm test?" in a window I wasn't looking at.

So I built VibeDesk, a full-screen Windows desktop around the real Claude Code CLI.

The idea: one dot per session

Every session gets a short name in a dock and a colored dot:

green: Claude is working
yellow (pulsing): Claude is waiting for you
blue: done

That alone fixed most of my problem. I glance down, see a yellow dot, click it.

Permission prompts as cards

When Claude wants to run a command, VibeDesk shows a card with the command and four buttons: In terminal, Deny, Always, Allow. One click, and the session keeps going. No hunting for the right terminal.

The same card shows up on your phone if you pair it (6-digit code, local network by default). Your phone buzzes, you tap Allow from the kitchen.

A memory for each project

Claude Code forgets your project between sessions. VibeDesk gives every project a small "brain": Markdown notes with links between them (Obsidian-compatible) that Claude reads and writes through MCP. Decisions, pitfalls, conventions. New sessions start from there instead of exploring the whole repo again.

Claude can drive the desktop

VibeDesk also ships an MCP server for the desktop itself. In any session you can say "sort my windows", "zen mode on" or "tokyo scene with more rain", and Claude does it. It can even open your local dev server in the preview window after starting it.

How it's built

Electron, React, xterm.js with WebGL, node-pty. It doesn't replace or proxy anything: each terminal runs the normal claude command with your own Pro/Max plan or API key. MIT licensed, Windows 10/11, no telemetry.

And yes, most of the code was written by Claude Code itself, with me steering, testing and saying no a lot.

Try it

Download: https://github.com/fxd-gif/vibedesk/releases/latest
Website (one page per feature): https://fxd-gif.github.io/vibedesk/
Source: https://github.com/fxd-gif/vibedesk

Windows SmartScreen will warn because the installer isn't signed yet ("More info" → "Run anyway").

VibeDesk 2.0 ships on November 1, and the most-upvoted wish on GitHub goes in. I'd love feedback from people who run several sessions in parallel: what would you want to see at a glance?

DEV Community: Fred 🍓

My ASCII hero redrew every frame from scratch. Only 55 of 12,198 cells had changed.

How the field works

The tricks I built in

Then I measured

The trick I hadn't built: skip what didn't change

Reduced motion

What this doesn't prove

The short version

Starting Claude Code from Node on Windows: 6 things that broke for me

1. claude isn't an executable

2. Don't add /s, and don't quote the first token

3. Everything on that command line is an injection point

4. Your Electron environment leaks into Claude

5. Hook commands have to survive three shells

6. Line endings, when Claude edits through scripts

What this doesn't cover

Question

Claude Code wrote almost all of my app. My job turned into saying no.

When code is cheap, everything looks worth building

The no's that made it better

The model is great at "yes"

Taste is the job now

What this doesn't prove

Question

I was sure it was a memory leak. It was a glowing border using 131 % of a CPU core

The measurement

Suspect 1: the glow

Suspect 2: the rain that wasn't raining

Suspect 3: every line of terminal output

After

How I measured (and two traps)

What this doesn't prove

Question

15 YouTube Shorts, 2,674 views, 1 subscriber: promoting a dev tool without showing my face

The numbers (last 28 days)

What I tried

What I learned

1. The view count barely depends on the video

2. The Shorts feed is the wrong room

3. A 75-second video beat all 15 Shorts

4. One honest post here beat everything

5. The real funnel is after the click

What this doesn't prove

What I'm changing

Your turn

8 rules for Claude Code hooks that never get in Claude's way

1. Exit 0. Always.

2. Bring your own deadline

3. stdout is not a log

4. PermissionRequest is the one hook that should wait

5. On Windows, quote the path, not the program

6. No dependencies, no bundler

7. Survive your own restarts

8. Stop hooks: check stop_hook_active

The short version

VibeDesk 2.0 is out – every feature request shipped, and why 1.9 burned 131 % of a CPU core

Every open wish is in

The bug: 131 % of a core for a terminal spinner

Try it

Approve Claude Code permission prompts from anywhere with the PermissionRequest hook

The hook

A tiny example you can use today

Answering from another window, or your phone

Things that bit me

Detecting "waiting" in general

I kept missing Claude Code's permission prompts, so I built a desktop around it

The idea: one dot per session

Permission prompts as cards

A memory for each project

Claude can drive the desktop

How it's built

Try it

1. `claude` isn't an executable

2. Don't add `/s`, and don't quote the first token

8. Stop hooks: check `stop_hook_active`