Repository navigation
Windows: Bash commands spawn visible black console windows #28138
Description
Problem
On Windows, every time Claude Code executes a Bash command, a black console window briefly appears on screen. This is disruptive, especially during multi-step tasks that run many commands in sequence.
Root Cause
When Claude Code spawns bash.exe (Git for Windows) as a child process, it does not set the CREATE_NO_WINDOW process creation flag. Windows therefore creates a visible console window for each spawned process.
Expected Behavior
Bash commands should execute silently in the background with no visible console window, similar to how background processes behave in macOS/Linux.
Suggested Fix
Pass CREATE_NO_WINDOW (or windowsHide: true in Node.js child_process.spawn() options) when spawning shell processes on Windows.
Alternatively, expose a user-configurable setting in settings.json such as:
{
"windowsHide": true
}Environment
- OS: Windows 11 Enterprise
- Shell: Git Bash (
C:\Users\...\AppData\Local\Programs\Git\usr\bin\bash.exe) - Claude Code: VSCode extension / Desktop app
Activity
github-actions commentedon Feb 24, 2026
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
ilude commentedon Feb 25, 2026
Is this going to get addressed? I am stuck on 2.1.42 which seems to be the last working version before this bug was introduced!
I dug into it and here is what I can tell based on the available info to the public:
Windows: Console window flashing regression introduced in v2.1.45
Since v2.1.45, every tool call, hook execution, and MCP server startup on Windows spawns a visible
cmd.exe/conhost.exewindow that flashes on screen and steals keyboard focus. v2.1.42 is the last version without this behavior.This has been reported independently by many users across 14+ issues over the past two months with no official response. Posting this as a consolidated comment with root cause analysis to hopefully get some traction.
What happens
When Claude Code executes any tool (Bash, Grep, Glob, Read, etc.), runs a hook, or starts an MCP server, a black console window briefly appears and steals keyboard focus. If you're typing in another application, keystrokes get swallowed. If you have hooks running on every prompt or tool call, the flashing is nearly continuous. It makes Claude Code effectively unusable on Windows without pinning to v2.1.42.
Root cause analysis
The regression aligns precisely with the introduction of the session environment / shell snapshotting mechanism in v2.1.45. Here's the evidence:
windowsHide: truetochild_process.spawn()callswindowsHide: truefix from v2.1.27"Session environment not yet supported on Windows"(#26610) confirms the feature shipped without full Windows supportonecmdleak in$SHELLOPTS(#26481) shows the snapshotting mechanism usesbash -o onecmdto capture environment, and this flag leaks into user sessionswindowsHide: trueIS set in 12 places in the binary, but the ConPTY/SEA binary context causesconhost.exeallocation anyway — the new spawn paths introduced by shell snapshotting likely bypass or override these settingsAdditional changes in v2.1.45 that may contribute:
v2.1.47 made things worse with "Fixed hooks silently failing on Windows by using Git Bash instead of cmd.exe" (#25981), which created yet another spawn path. That same version also introduced hook path mangling on Windows (#26746) where backslash separators get stripped.
Related issues
Primary reports:
Duplicate/related reports:
-iflag in cygpath call (closed as dup)Same-root-cause regressions from v2.1.45:
onecmdin SHELLOPTS)Workarounds
DISABLE_AUTOUPDATER=1CLAUDE_CODE_GIT_BASH_PATHtoC:\Program Files\Git\bin\bash.exeWhat a fix probably looks like
Based on community investigation, the fix needs to ensure
windowsHide: true(or the Win32CREATE_NO_WINDOWflag) is set on allchild_process.spawn()andchild_process.exec()calls — including the ones introduced by the shell snapshotting mechanism in v2.1.45 and the hook execution path changed in v2.1.47. The MCP SDK also has a bug wherewindowsHideis conditional on"type" in processwhich only returnstruein Electron, so it's effectively alwaysfalsein Node.js (#24708).Environment
jphoenix-dev commentedon Feb 25, 2026
@ilude Are you on the "native" windows installer version or the older npm version? I've just checked and my working (i.e. cannot repro flashing behaviour) v2.1.56 CLI is running the older npm version.
Obviously both variants should be fixed and this bug has been around a long time with no substantive response, but if you need a workaround it might be worth trying the older npm install path. Alternatively hopefully flagging that possible differentiator might help Anthropic debug the issue.
ilude commentedon Feb 26, 2026
@jphoenix-dev I am using the npm version. I will try the native installer in the morning and let you know here if the issue still exist there or not.
ilude commentedon Feb 26, 2026
Update: Isolated hook flashing to
uv.exe+ missingwindowsHideon hook spawn path (v2.1.59, npm)Did systematic testing on v2.1.59 (npm) to isolate exactly what causes the console window flashing. The root cause is a combination of two factors.
Test methodology: Disabled all hooks, then re-enabled one at a time with different commands.
echo hook-firedpython script.pyuv run script.pyuv run --no-sync script.pyuvw run script.py(uv 0.9.7)uvw run script.py(uv 0.10.5)Why
echo/pythondon't flash butuvdoes:echoandpythonexecute inside the bash process that Claude Code already spawned for the hook — no new console window is allocated.uv.exeis a separate Windows console-subsystem binary that allocates its ownconhost.exe. On v2.1.42, this was invisible because Claude Code's hook runner passedwindowsHide: true(orCREATE_NO_WINDOW) to the parent shell, which propagated to child processes. On v2.1.45+, that flag was lost on the hook execution path, so uv's console window becomes visible.This explains why pinning to v2.1.42 fixed the issue entirely — the hooks were calling
uv runon both versions, but v2.1.42 suppressed the console window allocation that v2.1.45+ exposes.Even
uvw.exe(Astral's official windowless wrapper, astral-sh/uv#6801) still flashes in this context, confirming that the missingwindowsHide/CREATE_NO_WINDOWon Claude Code's hook spawn path is the primary issue.Workaround: Replace
uv runwith barepythonin hook commands. Pre-install any PEP 723 dependencies into system Python (e.g.,pip install pyyaml tree-sitter). Sincepythonruns inside the existing bash process rather than allocating a new console, it avoids the flashing entirely regardless of Claude Code version.Note: Internal tool calls (Bash, Read, Grep, Glob, Edit) did not flash with hooks disabled on v2.1.59 npm. This suggests the
windowsHideregression is specifically on the hook execution path, not the main tool spawn path. Others seeing flashing on non-hook tool calls may be hitting a different code path.@jphoenix-dev Haven't tested the native installer yet — this was all on the npm version. Will update when I do.
github-actions commentedon Mar 26, 2026
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
github-actions commentedon Apr 3, 2026
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.