Desktop app spawns empty, argument-less powershell.exe windows that never close

Description

The Claude desktop app spawns bare powershell.exe child processes with no command-line arguments at all — no -Command, no -File, nothing. Each one opens as an idle, empty interactive PowerShell console window (blank content, just a blinking cursor, tab title falls back to the raw exe path since nothing sets a window title) and is never closed or reused.

Environment

• App: Claude desktop (Windows Store package) Claude_1.20186.1.0_x64__pzs8sxrjxfjjc
• OS: Windows 11 Pro (10.0.26200)
• Shell: Windows PowerShell 5.1 (C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe)

Evidence

Process trace (via Get-CimInstance Win32_Process) during a single active session, several concurrent worktrees/tabs open:

ProcessId ParentProcessId Name           CreationDate         CommandLine
13060     17664           powershell.exe 2026.07.13 15:34:55  powershell.exe
11476     17664           powershell.exe 2026.07.13 15:34:57  powershell.exe
17640     17664           powershell.exe 2026.07.13 15:34:59  powershell.exe
11240     17664           powershell.exe 2026.07.13 15:35:43  powershell.exe

Parent of all four (PID 17664):

"C:\Program Files\WindowsApps\Claude_1.20186.1.0_x64__pzs8sxrjxfjjc\app\Claude.exe"
  └─ parent: explorer.exe

So these are launched directly by the Claude.exe app process (not by any user script, scheduled task, or Startup-folder item — those were independently audited and all use -WindowStyle Hidden or documented visible dashboards with distinct titles). Multiple were spawned within seconds of each other, consistent with a per-session/per-tab shell-detection or environment-probe step that doesn't pass a command and doesn't close the window afterward.

Impact

• Visible clutter: multiple blank, purposeless PowerShell windows accumulate during normal use of the desktop app (more sessions/tabs = more windows).
• Each idle console consumes a small but nonzero amount of memory/handles indefinitely until manually closed.

Expected behavior

Whatever probe/detection this is should either:

• run with -NoProfile -Command <probe> ; exit so the process exits immediately and no window ever appears, or
• run fully hidden (-WindowStyle Hidden) if it needs to stay resident, or
• close itself once the probe completes.

Repro

Not deterministically reproducible on demand — observed to occur during normal use with several Claude Code sessions/worktrees open concurrently. Happy to provide more process/handle detail if useful.