Windows: claude.exe spawns cmd.exe/bash.exe child processes without CREATE_NO_WINDOW, causing visible console flashes

Open 💬 1 comment Opened Jun 23, 2026 by Devinsq

Title

Windows: child processes (cmd.exe, bash.exe) spawned by the CLI briefly/intermittently show a visible console window

Environment

  • Claude Code version: 2.1.186
  • OS: Windows 11 Pro, build 10.0.26300.8697 (26H2)
  • Shell: Git Bash (C:\Program Files\Git\bin\bash.exe) as the configured Bash tool backend
  • Install path: C:\Users\deske\.local\bin\claude.exe

Summary

On Windows, claude.exe directly spawns several child processes via cmd.exe and bash.exe without setting a console-suppression flag (CREATE_NO_WINDOW / Node's windowsHide: true). When the spawned command takes more than an instant to run, Windows allocates a real console window for the child, which is visible on screen for the duration of that child process — anywhere from under a second to 60-90+ seconds depending on what the command is doing.

Reproduction / Evidence

Captured via Windows Security log auditing (Event ID 4688, process-creation, command-line logging enabled via auditpol + ProcessCreationIncludeCmdLine_Enabled). All of the following were observed with Creator Process Name = C:\Users\deske\.local\bin\claude.exe directly (no intermediate shell/plugin):

cmd.exe /d /s /c "npx ^"@playwright/mcp@latest^""
cmd.exe /d /s /c "npx -y @modelcontextprotocol/server-filesystem C:/Users/deske"
cmd.exe /d /s /c "tasklist | findstr /I "Code.exe Cursor.exe Windsurf.exe Devin.exe idea64.exe ...""
cmd.exe /d /s /c "git config --get user.email"
cmd.exe /d /s /c "%windir%\System32\REG.exe QUERY HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography /v MachineGuid"
reg.exe query HKEY_CLASSES_ROOT\claude /ve
reg.exe query HKCU\SOFTWARE\Policies\ClaudeCode /v Settings
reg.exe query HKLM\SOFTWARE\Policies\ClaudeCode /v Settings
"C:\Program Files\Git\bin\bash.exe" -c "node \"${CLAUDE_PLUGIN_ROOT}/bundle/capture.js\""
"C:\Program Files\Git\bin\bash.exe" -c "powershell -NoProfile -NonInteractive -WindowStyle Hidden -ExecutionPolicy Bypass -File \"${CLAUDE_PLUGIN_ROOT}/hooks/send-event.ps1\" -CliSource claude agent.prompt.submit"

Immediately following several of these, a conhost.exe 0xffffffff -ForceV1 process is created as a child of the spawned cmd.exe/bash.exe — confirming Windows allocated a fresh, visible console for it (no console was inherited/hidden from the parent).

Note: passing -WindowStyle Hidden to an inner PowerShell command (as in the send-event.ps1 example above) does not help — by the time PowerShell starts, bash.exe has already been allocated its own visible console as the immediate child of claude.exe. The fix has to be applied at the point claude.exe spawns the child process, not inside the script the child later runs.

Impact

User-visible: a black console window appears on top of/behind other windows during normal CLI operation (MCP server startup, git status checks, registry policy checks, IDE-detection scans), with no indication of what it is or why it appeared. Duration is unpredictable because it's tied to how long the spawned command takes (e.g., npx @playwright/mcp@latest resolving a package vs. a one-shot reg.exe query). This has been observed across many sessions over multiple days and is reproducible essentially every session.

Suggested fix

When spawning child processes on Windows (cmd.exe /c, bash.exe -c, npx, reg.exe, git.exe, etc.) for the CLI's own internal operations (MCP server bootstrap, IDE detection, registry/policy checks, git metadata reads, hook dispatch), set windowsHide: true (Node child_process) / CREATE_NO_WINDOW so no console window is allocated, the same way -WindowStyle Hidden is already applied to the inner PowerShell invocation in some of these call sites.

Workaround in use

Confirmed (via a live EnumWindows sweep) that a normal interactive session never produces a window of class ConsoleWindowClass — Windows Terminal panes are CASCADIA_HOSTING_WINDOW_CLASS, a different class entirely. Every flash traced back to a standalone legacy conhost window (conhost.exe ... -ForceV1) attached to one of these orphaned child spawns. We're running a 15ms-interval watcher that hides any ConsoleWindowClass window on sight as a client-side mitigation; the spawned process is unaffected and exits normally once hidden. This confirms the window is real and harmless to suppress, but it's a workaround, not a fix — the allocation still happens inside the CLI binary on every affected spawn.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗