Windows: Bash/PowerShell tool calls flash visible conhost window

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/14828
2. https://github.com/anthropics/claude-code/issues/51867
3. https://github.com/anthropics/claude-code/issues/44039

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Confirmed on Claude Desktop 1.7196.0.0 (Microsoft Store package) + Claude Code 2.1.138 on Windows 11. Adding process-trace evidence from a real session today.

Scope is broader than bash.exe/powershell.exe — every console subprocess spawned by Claude.exe flashes:

| Time | Process | Parent | Triggered by |
|------|---------|--------|--------------|
| every 5–15 s | taskkill /pid N /T /F | claude.exe | background-task cleanup |
| burst of 9 simultaneously | gh.exe pr view <branch> --json ... | claude.exe | PR-status check |
| as needed | cmd.exe /d /s /c prisma generate | claude.exe → node.exe (pnpm) | npm-script execution |
| as needed | cmd.exe /d /s /c node ./node_modules/vitest/vitest.mjs run ... | same | test runs |
| as needed | git remote -v, tzutil, git-remote-https, sh.exe (credential-manager) | mixed | git internals |

Captured by polling Win32_Process at 250 ms intervals from a separate pwsh window for 5 minutes. Each of these PIDs has claude.exe (C:\Program Files\WindowsApps\Claude_1.7196.0.0_x64__pzs8sxrjxfjjc\app\Claude.exe) in its ancestry, and each spawns a fresh conhost.exe that flashes for ~100–300 ms.

Frequency in practice: during normal use, flashes occur every 5–20 seconds. End-user perception was "every few minutes a terminal window flashes — it doesn't even open, just flashes" — they assumed scheduled-task or malware before tracing.

Suggested fix stands: pass CREATE_NO_WINDOW (0x08000000) for every CreateProcess call from the Claude.exe host when the child is a console app. Alternatively, DETACHED_PROCESS (0x00000008) if no inherited handles are needed. Affects all Bash/PowerShell tool calls and every node/pnpm/gh/git/taskkill they spawn transitively, because the missing flag propagates through default inheritHandles=true.

Workaround for users hitting this: launch claude from Windows Terminal directly — subprocesses inherit the existing console and stop flashing entirely.

**Confirming on Claude Desktop (Cowork) + Claude Code, Windows 11 — and flagging that the focus theft, not just the flash, is the severe part.**

We hit this constantly across a team on Win11. Same root cause, two symptoms:

1. Visual flash (this issue) — a conhost/Windows Terminal window blinks on every Bash/PowerShell tool call.
2. Focus theft (was tracked in #40334, closed as dup) — the spawned console takes foreground, so keystrokes get yanked out of whatever you're typing in. In agentic sessions with many tool calls, this makes the machine nearly unusable while Claude works.

Root cause matches the report: shells spawned without CREATE_NO_WINDOW (0x08000000). On Win11 with Windows Terminal as default, the console surfaces as a CASCADIA_HOSTING_WINDOW_CLASS window. Because it's a child of the foreground Claude.exe, it can grab foreground even with ForegroundLockTimeout maxed — so OS-level focus-steal mitigations don't help. The fix has to be at spawn time.

Suggested fix: pass CREATE_NO_WINDOW when spawning shell subprocesses on Windows; for the ConPTY path, create the pseudoconsole host hidden (STARTF_USESHOWWINDOW + SW_HIDE).

Stopgap for anyone suffering now: an AutoHotkey v2 watcher using SetWinEventHook(EVENT_SYSTEM_FOREGROUND) + a fast sweep that hides console-class windows on appearance and bounces focus back. Tourniquet, not a cure — happy to share.

High-impact for Windows users doing real agentic work. Would love to see the CREATE_NO_WINDOW fix prioritized.

Also reproduces on v2.1.178 (Windows 11), and it is not limited to Bash/PowerShell tool calls: every hook process Claude Code spawns (pwsh -File ...) flashes the same way, because none of these child processes are created with CREATE_NO_WINDOW. With several hooks configured the conhost windows steal keyboard focus while typing, so it is disruptive rather than just a flicker. Related: #61051. Fix is the CREATE_NO_WINDOW (0x08000000) flag on the child-process spawn.

Confirming this on a fresh environment, plus an extra data point and a feature suggestion.

Environment: Windows 11 Home, build 10.0.26200, anthropic.claude-code v2.1.181-win32-x64 (VS Code native extension), both Git Bash and Windows PowerShell 5.1 tools.

Extra confirmation method — Windows native process-creation auditing (Event ID 4688):
While debugging an unrelated recurring console flash on this same machine (turned out to be two unrelated background services, nothing to do with Claude Code), I enabled Process Creation auditing (auditpol /set /subcategory:"{0CCE922B-69AE-11D9-BED3-505054503030}" /success:enable — must use the GUID, the localized subcategory name fails silently on non-English Windows) and read the Security log (Event ID 4688, Get-WinEvent, requires an elevated session or it silently returns empty). Correlating timestamps confirmed exactly what's described here: every Bash/PowerShell tool call from Claude Code spawns bash.exe/powershell.exe → conhost.exe with no CREATE_NO_WINDOW/STARTF_USESHOWWINDOW flag, and that's reliably attributable down to the second once third-party causes are ruled out.

This confirms the root cause described above is exactly right, and also gives a way for anyone else investigating "is this Claude or something else" to verify with certainty (4688 + conhost.exe/cmd.exe/powershell.exe parent-child chain), since the UAC/elevation path is a separate question — these are all non-elevated tool calls.

Feature suggestion on top of the fix: rather than just always hiding the window, it'd be useful to expose this as a setting with a few states, since some users actually want the visibility as an "agent is currently running a command" indicator (especially during long agentic sessions where they're not looking at the editor):

• hidden (sensible default) — CREATE_NO_WINDOW, no window at all.
• visible — current behavior.
• visible-signed — visible but with a distinguishing window title/banner, so it's unambiguous that it's Claude Code and not some other process.

Happy to share the full 4688 correlation data if useful for triage.

Confirming on Warp on Windows 11 with 12 concurrent claude.exe sessions — flash frequency scales with session count

Environment:

• Claude Code 2.1.177 (via @anthropic-ai/claude-code npm global)
• Windows 11 Pro 26200
• Warp terminal (not Windows Terminal / not Claude Desktop)
• 12 concurrent claude.exe --enable-auto-mode sessions running in parallel Warp panes
• All 12 launched via Warp's PowerShell → claude shim

Process trace:

Ran a 500ms-interval Win32_Process poller for 90 seconds and captured 106 short-lived process events. After filtering out my own polling and unrelated background sessions, the dominant pattern is:

Parent: claude.exe
Child:  powershell.exe -NoProfile -Command "(Get-CimInstance Win32_Process -Filter \"ProcessId=27320\").CreationDate.Ticks"
+ conhost.exe (spawned as sibling)

PID 27320 is the primary claude.exe session in my setup. Each of the 12 claude.exe processes independently polls the primary session's CreationDate.Ticks on a roughly 1–3 second cadence, which looks like liveness/health tracking. That comes out to ~4–12 powershell spawns per second, each generating a conhost.exe that flashes for ~100–300ms.

None of these child processes carry -WindowStyle Hidden, and per the earlier comments the underlying child_process.spawn call site is missing windowsHide: true.

Multi-session scaling:

With N concurrent CLI sessions doing agentic work, the flash rate is roughly N × (Bash-tool-calls-per-second + liveness-polls-per-second). At N=12, keystroke loss becomes the primary UX symptom — characters typed into an editor often land in a conhost that flashes and disappears before Windows re-focuses. The visual flash is secondary.

Warp on Windows may not benefit from the Windows Terminal workaround.

The workaround floated in #66540 ("launch claude from Windows Terminal so child processes inherit the console") relies on wt.exe providing a proper attached conhost. Warp on Windows uses its own PTY implementation, and my 12 claude.exe processes here still spawn fresh conhost windows despite being launched from Warp panes (not from Claude Desktop). I have not yet A/B tested against wt.exe directly — sharing as a data point in case Warp coverage matters for the fix design.

On the fix:

Reiterating the shape already discussed: windowsHide: true on child_process.spawn call sites (or CREATE_NO_WINDOW at the CreateProcess flag). Happy to gather additional traces or run an A/B test against wt.exe if that would help triage.

Adding another spawn-site data point that isn't yet listed above (MCP stdio / Bash tool / subagent spawning / Codex plugin): hook commands (UserPromptSubmit, SessionEnd, etc. defined in .claude/settings.json) also trigger this.

Each "type": "command" hook entry is executed as a shell command (e.g. pnpm --dir "<path>" exec tsx scripts/foo.ts) on every matching event — for us, 3 hooks fire on every UserPromptSubmit and 2 more on every SessionEnd. On Windows, under Claude Desktop (no inherited console), each of those fires its own conhost.exe/cmd.exe flash, same root cause as described above (no console to inherit → new window per spawn). With several prompts/sessions in a day this alone produces bursts of 20-30 flashing windows, independent of any MCP servers or Bash tool usage.

Confirms the fix needs to cover the hook-execution spawn path too, not just MCP/Bash/subagent/Codex spawn sites.