Windows: Bash/PowerShell tool calls flash a visible console window on the desktop

Description

On Windows 11, every Bash/PowerShell tool call made by Claude Code inside a desktop-app session spawns a visible console window on the real desktop (a cmd.exe/powershell.exe + conhost.exe process chain), rather than running fully in the background/hidden. This happens even with:

• The Windows 11 "Default terminal application" setting (Settings -> Privacy & security -> For developers -> Terminal) set to Windows Console Host instead of Windows Terminal.
• No Task Scheduler, wscript.exe, or other launcher chain involved -- this reproduces on a plain Bash/PowerShell tool call issued directly by Claude inside a normal (non-background) turn.

During a long session with frequent tool calls (diagnosing an unrelated issue, dozens of PowerShell/Bash invocations), this produces a highly visible, repeated window flash on the user's screen that could not be suppressed from within the session -- confirmed by directly correlating Get-Process timestamps of powershell.exe/cmd.exe/conhost.exe process creation with the exact moments tool calls were issued.

Environment

• OS: Windows 11 Home Single Language 10.0.26200
• Claude Code: desktop app (Code tab)
• Shells used: PowerShell 5.1 and Git Bash (both tools exhibit the same behavior)

Expected behavior

Bash/PowerShell tool calls should execute without ever creating a visible window on the user's desktop, regardless of the Windows "default terminal application" setting -- e.g. by launching the child process with CREATE_NO_WINDOW / a hidden window station, similar to how pythonw.exe (a GUI-subsystem binary) never gets a console at all.

Actual behavior

A console window flashes on screen for (at least part of) the duration of each tool call. Over a session with many rapid tool calls, this is disruptive to the user's other work on the same desktop.

Steps to reproduce

1. Open a Claude Code session in the desktop app on Windows 11.
2. Ask Claude to run several PowerShell or Bash commands in sequence (e.g. Get-Process, git status, etc.).
3. Observe a console window appearing/flashing on the real desktop for each call, even with Windows Console Host set as the default terminal app.

Additional notes

This was diagnosed empirically in a live session by:

• Confirming a WindowsTerminal.exe process was created and destroyed in the same second as a tool call.
• Later confirming powershell.exe/cmd.exe/conhost.exe processes with StartTime exactly matching tool-call timestamps.
• Ruling out all other candidate sources (Task Scheduler tasks, a Windows Service running in Session 0, other background apps) via direct process/event-log inspection.