PowerShell tool spawns a bare, visible powershell.exe host window (Windows)

Environment

• OS: Windows 11 Home 10.0.26200
• Claude Code (desktop app): 2.1.271
• Shell config: PowerShell tool as primary, Bash tool also available

Summary

Invoking the built-in PowerShell tool spawns a bare powershell.exe (no arguments, no -WindowStyle Hidden, no console suppression) as its backing shell process. Since the Claude Code desktop app is a GUI process with no console of its own, Windows must give this child a console — and because Windows Terminal is the default terminal application, it gets hosted in a fully visible WindowsTerminal.exe window titled "Windows PowerShell". This steals focus and interrupts whatever the user is doing in another window.

This happens before any PreToolUse hook even runs — I confirmed it fires even when a PreToolUse hook denies the tool call outright, so it's the tool's own process startup, not anything scriptable/hookable from user config.

Impact

Every session's first use of the PowerShell tool (and possibly every use — see below) produces one visible, focus-stealing window flash. On a workstation running several concurrent Claude Code sessions, this presents as frequent, seemingly random console flashes throughout the day, which is difficult for users to diagnose because:

• It is not caused by any hooks entry in settings.json.
• It is not caused by any MCP server registration.
• It is not caused by any scheduled task.
• -WindowStyle Hidden is not applicable since the user has no control over this spawn at all.

Repro

1. On Windows, with Windows Terminal set as the default terminal application (the Windows 11 default).
2. In a Claude Code session, invoke the PowerShell tool with any command.
3. Observe a WindowsTerminal.exe window titled "Windows PowerShell" become visible momentarily.

Diagnosis method

Verified with a live EnumWindows watcher (via a short ctypes script) polling for visible windows of class ConsoleWindowClass / CASCADIA_HOSTING_WINDOW_CLASS while exercising both tools in the same session:

• Multiple Bash tool calls: zero visible console-class windows observed.
• One PowerShell tool call: one visible CASCADIA_HOSTING_WINDOW_CLASS window appeared, titled "Windows PowerShell", traced via Get-CimInstance Win32_Process back to a bare powershell.exe process with an empty command line, itself parented by a COM-activated WindowsTerminal.exe -Embedding process (i.e., DCOM launch of the default terminal host) — not by any hook, MCP server, or scheduled task on the machine.

Suggested fix

Spawn the PowerShell tool's backing process with CREATE_NO_WINDOW (and ideally via a pythonw/GUI-subsystem-style detached launch, or STARTUPINFO.dwFlags = STARTF_USESHOWWINDOW + wShowWindow = SW_HIDE combined with CREATE_NO_WINDOW), the same way a well-behaved hook launcher must, so it never allocates a visible console/terminal window regardless of the user's default terminal application setting.

Workaround

Users can avoid the flash entirely by preferring the Bash tool over the PowerShell tool whenever the command doesn't require PowerShell-specific cmdlets.