tracking: Windows console window flashes on every hook/tool-use — missing windowsHide and cmd.exe wrappers in spawn paths

[thedotmack]

Root Cause

Multiple spawn paths in the worker and hook scripts are missing windowsHide: true or route through cmd.exe unnecessarily. The primary culprits are: findBun() using spawnSync('where bun', { shell: true }) without windowsHide; hooks using "shell": "bash" from a GUI context (VS Code); git subprocess calls (rev-parse, ls-files, cat-file) lacking windowsHide; and the SDK transport resolving the Claude CLI to a .cmd npm shim which forces a cmd.exe /d /c wrapper. Any of these paths causes a visible conhost/black console window flash on each hook or tool-use event.

Tracked Items

Issues

• Closes Windows: worker daemon flashes a console window on every observation/summarize (claude.cmd spawned via cmd.exe) #2946 — Windows: worker daemon flashes a console window on every observation/summarize (claude.cmd spawned via cmd.exe) #2946
• Closes 每次对话，或是回答，就会有一些窗口一闪而过非常快，经常会被晃到不舒服，影响使用体验； #2913 — 每次对话，或是回答，就会有一些窗口一闪而过非常快，经常会被晃到不舒服，影响使用体验； #2913
• Closes [Windows] git subprocess calls in worker-service.cjs lack windowsHide -> console windows flash constantly #2900 — [Windows] git subprocess calls in worker-service.cjs lack windowsHide -> console windows flash constantly #2900
• Closes [Windows] Hook execution flashes black console window on every tool use #2869 — [Windows] Hook execution flashes black console window on every tool use #2869

PRs

• Related PR fix(windows): hide cmd window in where bun spawnSync (findBun) #2944 — fix(windows): hide cmd window in where bun spawnSync (findBun) #2944
• Related PR fix(windows): carry windowsHide through the remaining live Windows spawn paths (closes #2900) #2921 — fix(windows): carry windowsHide through the remaining live Windows spawn paths (closes #2900) #2921
• Related PR fix(windows): suppress console window flash in findBun() spawnSync call (closes #2869) #2890 — fix(windows): suppress console window flash in findBun() spawnSync call (closes #2869) #2890

Resolution

This is the canonical tracking issue for this root cause. Individual issues and PRs listed above will be closed in favor of this one.

[MarcHuberItme]

Tested fix for the two cmd.exe-per-hook spawns in bun-runner.js, plus a finding on the remaining PowerShell flashes

Environment: Windows 11, Claude Code, claude-mem 13.6.2, bun.exe at %USERPROFILE%\.bun\bin\bun.exe, runtime=worker.

I instrumented this with a Get-CimInstance Win32_Process poller (35 ms) that logs every short-lived cmd.exe/powershell.exe/conhost.exe with its parent/grandparent and command line. Findings below are from that capture.

1. Confirmed: every hook spawns two visible cmd.exe windows from bun-runner.js

cmd.exe /d /s /c "where bun"                                   # findBun()
cmd.exe /d /s /c ""bun" "...\worker-service.cjs" "hook" ...""  # main spawn

Both come from scripts/bun-runner.js:

• findBun() runs spawnSync('where bun', { shell:true }) on every hook → cmd.exe.
• The main spawn sets spawnOptions.shell = true and builds cmd.exe /d /s /c "bun" …. Even though windowsHide:true is set, the chain cmd.exe → (bun.cmd/PATH) → bun.exe makes bun.exe allocate a fresh visible console, because the hidden cmd.exe parent has no console to inherit.

Fix (tested, no more cmd.exe in the capture after applying):

1. In findBun(), check well-known install paths first so where/cmd.exe is never spawned when bun is in its usual location; and if the PATH lookup is still needed, use spawnSync('where', ['bun'], { windowsHide:true }) (no shell:true) and prefer the bun.exe line over bun.cmd.
2. In the spawn section, when the resolved bun path ends in .exe, spawn it directly (spawnCmd = bunPath; spawnArgs = args;) with no shell:true. Direct-spawning the .exe lets the already-present windowsHide:true apply CREATE_NO_WINDOW, so nothing flashes. Keep the old shell:true quoting path only as the non-.exe fallback.

After this, the process monitor shows the worker launching as bun.exe PARENT=node.exe …worker-service.cjs hook … with zero cmd.exe. node --check passes and … status still works.

2. Remaining flashes: powershell.exe under bun still flashes despite windowsHide:!0

Once cmd.exe was gone, the screen still flickered. The remaining short-lived processes per hook are:

powershell.exe PARENT=bun.exe   ... (Get-CimInstance Win32_Process -Filter "ProcessId=<workerPid>").CreationDate...
powershell.exe PARENT=bun.exe   ... CredRead "Claude Code-credentials" (P/Invoke, subscription auth)
powershell.exe PARENT=claude.exe ... parent-PID walk + CreationDate.Ticks   (the spawned Claude Code SDK doing its own session resolution)

All of these already pass windowsHide:!0 in the source. The key point: the worker runs under bun, and bun's child_process.spawnSync/spawn does not reliably honor windowsHide on Windows (the conhost window still appears). So setting the flag is not sufficient under the bun runtime — these PowerShell calls flash on every hook.

Suggestions for this second class:

• Don't shell out to PowerShell per hook from the short-lived client. The OAuth-token read (CredRead) and the worker CreationDate liveness check are invariant for the daemon's lifetime — resolve them once in the daemon and serve cached values over the existing worker socket, instead of re-spawning PowerShell on every PostToolUse.
• Where a Windows API value is still needed, prefer a native binding over powershell.exe so there is no console process at all (sidesteps the bun windowsHide gap entirely).
• If PowerShell must be spawned, verify behavior specifically under bun, and consider routing via a hidden launcher rather than relying on windowsHide alone under bun.

Happy to open a PR for the bun-runner.js part (item 1) if useful — it's a small, self-contained change.