PowerShell 7.6.x crashes with "Unknown Hard Error" on launch (0xE9 / ERROR_NO_DATA via ConPTY)

[codingseb]

Pre-submit Checks

• I have searched Warp bugs and there are no duplicates
• I have searched Warp known issues page and my issue is not there
• I have an issue with AI and have included the debugging ID (Optional, but helps expedite the AI quality fix). Debugging ID instructions
• I have technical issue and have included the logs (optional, but helps expedite the bug fix). Log instructions

Describe the bug

When Warp launches PowerShell 7.6.x (pwsh.exe) as its session shell on Windows 11,
pwsh fails fast immediately at startup and Windows displays an "Unknown Hard Error"
dialog (pwsh.exe — Avertissement système). The tab closes before any prompt is rendered.

The same pwsh 7.6.1 binary launched outside Warp (Win+R → pwsh, or from Windows Terminal)
works fine. Downgrading to PowerShell 7.5.x also makes the issue disappear in Warp.

Root cause appears to be the bundled ConPTY pair (OpenConsole.exe / conhost.exe) in Warp
being older than the version pwsh 7.6 / .NET 10 expects when calling
GetConsoleScreenBufferInfo. The exact same symptom was tracked and fixed in WezTerm by
bumping the bundled ConPTY pair to 1.24.260402001:
wezterm/wezterm#7774

To reproduce

1. Install PowerShell 7.6.1: winget install Microsoft.PowerShell --force
2. In %LOCALAPPDATA%\warp\Warp\config\settings.toml set:
   [session.new_session_shell_override]
   executable = 'C:\Program Files\PowerShell\7\pwsh.exe'
3. Open a new Warp tab/window → "Unknown Hard Error" dialog appears, pwsh exits.

Windows Event Viewer → Application log captures:
Application: pwsh.exe
CoreCLR Version: 10.0.626.17701
.NET Version: 10.0.6
System.Environment.FailFast
Message: The Win32 internal error "No process is on the other end of the pipe." 0xE9
occurred while getting console output buffer information.

Expected behavior

pwsh 7.6.x should launch normally inside Warp, as it does in Windows Terminal,
conhost, and in WezTerm after the ConPTY bump (wezterm#7774).

Screenshots, videos, and logs

warp-logs.zip

Operating system (OS)

Windows

Operating system and version

Windows 11 Pro 22631 (10.0.22631)

Shell Version

PowerShell 7.6.1 (C:\Program Files\PowerShell\7\pwsh.exe)

Current Warp version

v0.2026.05.18.05.32.stable_02

Regression

No, this bug or issue has existed throughout my experience using Warp

Recent working Warp date

No response

Additional context

Runtime: .NET 10.0.6 / CoreCLR 10.0.626.17701

Does this block you from using Warp daily?

No

Is this an issue only in Warp?

Yes, I confirmed that this only happens in Warp, not other terminals.

Warp Internal (ignore): linear-label:b9d78064-c89e-4973-b153-5178a31ee54e

None

[oz-for-oss]

@codingseb

Here's what I found while triaging this issue:

Thanks for the detailed report. The available evidence points to a Windows PTY/PowerShell 7.6 launch compatibility issue in Warp; using PowerShell 7.5.x appears to be a reasonable temporary workaround based on your reproduction.

Maintainer details

I concluded that powerShell 7.6.1 fails fast on Windows when launched as Warp's session shell, likely through Warp's bundled ConPTY/OpenConsole path..

Triage summary

This looks like a Windows shell-launch/PTY bug rather than a PowerShell profile issue. The report gives a strong reproduction path for PowerShell 7.6.1 on Windows 11 and includes the key Event Viewer failure (Environment.FailFast with Win32 0xE9 while getting console output buffer information).

Evidence

• Affects Warp v0.2026.05.18.05.32.stable_02 on Windows 11 Pro 22631 with C:\Program Files\PowerShell\7\pwsh.exe 7.6.1 / .NET 10.0.6.
• The same pwsh.exe works outside Warp, and downgrading to PowerShell 7.5.x avoids the crash in Warp.
• Warp's Windows PTY spawn path loads bundled conpty.dll and uses bundled OpenConsole.exe assets copied by the build (app/build.rs), then creates the shell through CreatePseudoConsole and CreateProcessW (app/src/terminal/local_tty/windows/).
• The reporter's WezTerm reference is plausible supporting evidence, but the ConPTY asset version still needs to be verified in Warp's Windows build before treating it as confirmed root cause.

Duplicate check

I enumerated all open non-PR issues and checked recent closed issues. Related Windows ConPTY/PowerShell crash issues exist (#10821, #10051, #10803), but those center on Ctrl+C / foreground app termination rather than PowerShell 7.6 failing at session launch. Since fewer than two existing issues share this launch-time reproduction, I am not marking this as a duplicate.

Follow-up

No reporter follow-up is needed for initial routing; the report already includes the environment, reproduction steps, comparative terminal behavior, screenshot, and logs.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz

[acarl005]

Hi @codingseb thanks for reporting the issue. I'm going to rebase our forked version of ConPTY on the latest stable release. I'll send you a pre-release build to test if it fixes the issue.

[acarl005]

Ok @codingseb can you try installing and running this build to see if it fixes the issue?

https://releases.warp.dev/preview/v0.2026.05.20.09.21.preview_01/WarpPreviewSetup.exe

[codingseb]

Ok @codingseb can you try installing and running this build to see if it fixes the issue?

https://releases.warp.dev/preview/v0.2026.05.20.09.21.preview_01/WarpPreviewSetup.exe

Hello @acarl005, thanks for your quick answer.

I installed the pre-release and unfortunately the error is still there.

To rule out a corrupted profile, I backed up and completely removed my PowerShell profile --> no change.

While testing, I noticed a clearer reproduction pattern:

• The error now occurs most often when closing Warp, not at startup as initially reported.
• It happens specifically when I close Warp while a Claude Code session is running in a PowerShell tab.
• On the next launch, Warp tries to restore that session, fails to reattach it, and the tab hangs.
• If a Claude Code session is not running when I close Warp, the next launch works fine — until I relaunch Claude Code and close Warp again.
• Exiting Claude Code (Ctrl+D / /exit) before closing Warp makes the error disappear entirely.
• I ran the same test with Codex CLI: Warp's restored command block disappears at next start, but no "Unknown Hard Error" is thrown.

Cross-check with Windows Terminal

I ran the exact same scenario in Windows Terminal (same PowerShell 7.6.x, same Claude Code session, closing the window with Claude Code still running, then reopening — session restore enabled):
no crash, no Unknown Hard Error, the new tab launches cleanly.

So the bug is not in PowerShell 7.6 / .NET 10 / Claude Code's raw-mode handling per se — it's specifically in how Warp tears down and/or
restores a ConPTY that still has an active child process attached. Windows Terminal seems to either reap the process tree properly on close, or start a fresh PTY on restore rather than reattaching to the previous one.

Hypothesis (asked to Claude code 😉)

Claude Code (Node.js / Ink-based TUI) puts the console into raw mode + alternate screen buffer and installs its own signal handlers. When Warp is closed, the pwsh + node process tree doesn't get a clean teardown — which is why the error surfaces at exit time: Warp tears down the ConPTY while node is still holding the pipe in raw mode, triggering the failed GetConsoleScreenBufferInfo call (0xE9 / ERROR_NO_DATA). On the next launch, the session-restore feature then tries to reattach to that broken PTY state and the tab hangs.

Since Windows Terminal handles the same scenario without any crash, the ConPTY version bump alone is unlikely to be the full fix.
Warp's shutdown path probably needs to send a proper close signal to the foreground process (or wait for the child process tree to be reaped) before tearing down the ConPTY, and the session-restore path should fall back to a fresh PTY when reattachment fails.

Workarounds that help in the meantime

• Always exit Claude Code before closing Warp.
• Disabling Warp's "restore tabs/sessions" option avoids the hang on next launch (at the cost of losing session restore).
• Downgrading to PowerShell 7.5.x as previously mentioned.

I can live with it for now.

[jdivy]

In the event it is helpful, this particular issue sounds identical to something I experience from time to time whereby restarting Warp hangs on a fresh startup when trying to reconstitute previous sessions. The entire app shell is unresponsive (I can't even close the window with the 'X') and I have no recourse other than terminating the process via Process Explorer. Various menus can be opened and clicked but nothing actually happens - e.g. I'll want to go to the 'View Warp logs' but clicking that button does absolutely nothing.

Until I close all previous agent sessions Warp was trying to reconstitute (that are all stuck showing "Starting shell...") Warp will not start up cleanly. It feels like the session-restore breaks the parent process (or gets it into a deadlock somewhere) when this happens.