Windows: taskkill.exe spawned without window suppression flashes a console window on the desktop

Summary

On Windows, Claude Code spawns taskkill.exe to terminate process trees without console-window suppression. Each spawn allocates a console, which on Windows 11 (default terminal application delegated to Windows Terminal) surfaces as a new terminal window that appears and vanishes within a few hundred milliseconds — a visible flash on the user's desktop, repeated throughout a session.

Claude Code's Bash tool spawns are already suppressed correctly. Only the process-kill path appears to be missing the flag, so the fix looks localized.

Environment

• Claude Code 2.1.228
• Windows 11 Pro, build 26200 (10.0.26200)
• Windows Terminal 1.24.11911.0 — default terminal application left at the Windows default, which delegates to Windows Terminal
• Node v22.19.0
• Shell: Git Bash

Evidence

I traced the flashing window's console back through process ancestry. The console belongs to taskkill.exe, spawned as a direct child of claude.exe:

conhost.exe                 <- hosts the visible console window
  <= taskkill.exe           <- taskkill /PID <pid> /T /F
    <= claude.exe

There is no shell process between claude.exe and taskkill.exe — unlike every hook and Bash tool call I observed, which all show bash.exe in the chain. Scanning all session transcripts on the machine across a 3-hour window found zero agent-authored taskkill commands, which confirms the spawn originates inside Claude Code rather than from a tool call.

Contrast measurement

Over 8 minutes of heavy tool traffic, the machine saw 118 console allocations but zero visible console windows — so Bash tool spawns are correctly windowless. Visible flashes appeared only alongside process-tree teardowns.

A measurement note that may save maintainer time

CREATE_NO_WINDOW allocates a console without a window but still spawns a conhost.exe. Counting conhost creations therefore does not measure user-visible flashes — a correctly suppressed spawn is indistinguishable from a bad one by that signal.

The honest discriminator is a top-level window that becomes visible with class ConsoleWindowClass (classic conhost) or CASCADIA_HOSTING_WINDOW_CLASS (modern conhost / Windows Terminal).

One further trap: with default-terminal delegation, the flashing window's owning process is the pre-existing WindowsTerminal.exe, not the offending process. Window ownership alone misattributes the cause, which is probably why this is easy to miss in testing.

Reproduction

1. Windows 11, default terminal application left at the Windows default (Windows Terminal).
2. In a Claude Code session, run a workflow that repeatedly spawns and tears down child process trees. Any CLI that launches a browser and closes it once per invocation works well, since each teardown triggers a kill.
3. Watch the desktop: a console window flashes once per teardown.

Frequency tracks teardown count rather than a timer, which makes it feel intermittent and hard to pin down.

Expected behaviour

No console window appears. taskkill.exe is spawned with window suppression — windowsHide: true on the Node child_process call, or CREATE_NO_WINDOW — matching how Bash tool spawns are already handled.

Impact

On a machine the user is actively working at, a console window flashing repeatedly is disruptive, and it is unusually hard to self-diagnose: the process has exited before it can be inspected, and the window's apparent owner is the user's own terminal.