claude-code - 💡(How to fix) Fix [BUG] pwsh.exe FailFast (0xE9 ERROR_PIPE_NOT_CONNECTED) in ConsoleHost.Start, triggered by spawned statusline / hook subprocesses on Windows

Preflight Checklist

• I have searched existing issues — closest related is #14828 (different symptom; see Additional Information)
• This is a single bug report
• I am using the latest version of Claude Code (2.1.145)

What's Wrong?

On Windows, pwsh.exe (PowerShell 7) child processes spawned by Claude Code intermittently crash with System.Environment.FailFast during pwsh startup — before any user script runs. This produces a modal Windows "Unknown Hard Error" popup that grabs foreground focus and blocks the user until acknowledged.

The exception is System.Management.Automation.Host.HostException thrown by Microsoft.PowerShell.ConsoleHost.Start while retrieving the active console output buffer handle, with Win32 error 0xE9 (ERROR_PIPE_NOT_CONNECTED — "No process is on the other end of the pipe").

Captured evidence implicates the statusline render path: in every captured event, a live pwsh -NoProfile -NonInteractive -File ...statusline-command.ps1 is present whose parent process has already exited. The dying pwsh appears to be racing against a parent that closes its stdio pipes immediately after spawning the child.

This is the well-known upstream pwsh startup race (PowerShell/PowerShell#16818, microsoft/terminal#14511) — Microsoft has not fixed it, and pwsh treats the failure as fatal via FailFast, which is what surfaces the hard-error popup instead of a silent error. Claude Code's spawn pattern (high-frequency, short-lived parent, piped stdio) is a near-perfect trigger.

What Should Happen?

• The statusline render path should not produce a modal OS-level popup, ever.
• High-frequency pwsh spawns should be avoided where possible (e.g. by reusing a long-running pwsh worker for repeated statusline renders).
• If a spawned pwsh does FailFast on startup, Claude Code should detect the abnormal exit and silently retry / log, not surface a blocking system popup.

Error Messages/Logs

--- FailFast at 2026-05-20T13:06:48 (Application event log RecordId 71999) ---
Description: The application requested process termination through System.Environment.FailFast.
Message: The Win32 internal error "No process is on the other end of the pipe." 0xE9 occurred
while retrieving the handle for the active console output buffer. Contact Microsoft Customer
Support Services.

System.Management.Automation.Host.HostException
   at Microsoft.PowerShell.ConsoleHost.Start(String bannerText, String helpText, Boolean issProvidedExternally)
   at Microsoft.PowerShell.UnmanagedPSEntry.Start(String[] args, Int32 argc)

Stack:
   at System.Environment.FailFast(System.Runtime.CompilerServices.StackCrawlMarkHandle, System.String, System.Runtime.CompilerServices.ObjectHandleOnStack, System.String)
   at System.Environment.FailFast(System.Threading.StackCrawlMark ByRef, System.String, System.Exception, System.String)
   at System.Environment.FailFast(System.String, System.Exception)
   at Microsoft.PowerShell.UnmanagedPSEntry.Start(System.String[], Int32)
   at Microsoft.PowerShell.ManagedPSEntry.Main(System.String[])

Live pwsh processes at capture time (relevant entries):
  pid=10304 ppid=8440(<parent already exited>): pwsh -NoProfile -NonInteractive -File C:/Users/<me>/.claude/statusline-command.ps1
  (plus 6 pwsh processes parented by WindowsTerminal.exe, each parent of a claude.exe + node MCP server)

--- FailFast at 2026-05-20T16:19:08 (RecordId 72032) ---
[Identical stack trace]
Live pwsh: pid=43992 ppid=37464(<parent already exited>): pwsh -NoProfile -NonInteractive -File ...statusline-command.ps1

Steps to Reproduce

Intermittent and timing-dependent — fires on the order of once per few hours per machine under normal Claude Code use.

1. On Windows 11, install Claude Code 2.1.145 and pwsh 7.
2. Configure a statusline command in ~/.claude/settings.json:

   "statusLine": {
     "type": "command",
     "command": "pwsh -NoProfile -NonInteractive -File C:/Users/<me>/.claude/statusline-command.ps1",
     "padding": 0
   }

   Any pwsh-based statusline script works — the script body is irrelevant; the crash happens before it runs.
3. Use Claude Code normally (multiple concurrent sessions accelerates the rate).
4. Within hours, an "Unknown Hard Error" popup will appear.

Detection method (since the crash is hard to catch live): a background watcher polled the Windows Application event log every 5s for .NET Runtime event ID 1025 with pwsh.exe in the message, and on each new event snapshotted live pwsh.exe processes with their parent PID and parent process name. Two captures matching the signature above were collected over ~5 hours.

Claude Model

Not sure / Multiple models — bug is in subprocess spawning, model-independent.

Is this a regression?

I don't know — first time investigating. The popups have been recurring for some time but I don't have a clean baseline of when they started.

Last Working Version

N/A

Claude Code Version

2.1.145 (Claude Code)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

Related issue: #14828 (Windows console window flashing during tool execution) — different symptom (cosmetic flash vs. hard crash + modal popup) but same general area (Windows subprocess spawning options). Commenters there have identified missing windowsHide: true in the spawn() call as a contributing factor for the flash bug; it's plausible (but unconfirmed) that spawn flag changes also affect the FailFast race here.

Suggested investigation, in rough priority order:

1. Reuse a long-running pwsh worker for repeated statusline renders — pipe successive session JSON over a persistent stdin instead of spawning fresh pwsh per refresh. This sidesteps the ConsoleHost.Start race entirely and is the biggest win.
2. Throttle/coalesce statusline renders to lower the spawn rate.
3. Detect 0xE9 FailFast exit on the child and silently retry, so a single race doesn't produce a user-visible popup.
4. Audit other high-frequency pwsh-spawning paths (hooks, MCP stdio servers configured to use pwsh) — same root cause likely applies.

Upstream references:

• PowerShell/PowerShell#16818 — ConsoleHost.Start startup race
• microsoft/terminal#14511 — same race from the terminal side

Full watcher logs and parent-process snapshots are available on request.