[mortenaslo]

Sessions now run on Microsoft's current ConPTY (Microsoft.Windows.Console.ConPTY 1.25.260930003, stable, Microsoft-signed, MIT) instead of the one built into Windows. Windows Terminal and VS Code do the same.

Why

Measured against conhost 10.0.26100:

1. The built-in ConPTY drops OSC sequences written back to the program, for example colour replies and OSC 7501 replies.
2. It answers the DA1 query itself, so any reply that has to come from the real terminal arrives too late.

The bundled ConPTY does neither: raw OSC input arrives intact, and DA1 is forwarded to xterm.js. Claude Code 2.1.319 logs programStatus=no (probe: no reply to OSC 7501 ; ?) on the built-in ConPTY and programStatus=yes (probe: OSC 7501 reply) on the bundled one. This unblocks OSC 7501 status reporting in #187, for any program that checks for support before reporting, not only Claude.

What changes

• Packaging: both files ship as loose files beside the exe in the build output, the single-file publish, the MSI and the ZIP. They come from a PackageReference, not binaries committed to git, and the architecture is picked per build (x64 by default).

• Loading: conpty.dll is loaded by full path only (AppContext.BaseDirectory, function pointers), never by bare name, which avoids DLL search-order hijacking. kernel32 is loaded from System32 by full path.

• Fallback to the built-in ConPTY, logged to crash.log, when any of these hold:

  • UseBundledConPty is false
  • a file is missing
  • loading the DLL fails
  • creating a console fails 3 times in a row (a single failing terminal retries on the built-in ConPTY regardless)

  Resize and close always go to the ConPTY that created the console.

• Early output is kept: output that arrives before the first subscriber is buffered and delivered in order. Sessions attach after Start, and the bundled ConPTY's first bytes include a DA1 query that xterm.js must answer.

• Run commands stay on the built-in ConPTY. They are headless, and the bundled one leaves a program's own DA1 query unanswered there (measured). Their startup is unchanged: 45 ms vs 44 ms median.

• Escape stripping: the three escape-stripping regexes now also strip ESC[1t / ESC[c, so they stay out of search.

• CI and signing:

  • CI fails if the MSI or the publish output lacks either file, or if either file is not validly Microsoft-signed.
  • Exe signing now targets CodeShellManager.exe only. The old folder filter would have re-signed Microsoft's OpenConsole.exe with our certificate.

Review

A read-only review found one real race: the first PTY output, including the startup DA1 query, could be dropped before the bridge subscribed. It also flagged x64-only package paths and a single failure permanently switching the process to the built-in ConPTY. All three are fixed in the second commit. Loader security, the function-pointer signatures, the WiX layout, the signing input and the regex scope were checked and found sound.

Verified

• 782 unit tests pass (17 new: loader/fallback, early-output ordering under concurrency, failure policy).
• UI tests 10/10 on this build, with test(ui): make the FlaUI suite pass again, without the mouse or keyboard #184's test fixes applied.
• Resize, exit detection, the job-object kill, throughput and hard-kill cleanup behave the same on both ConPTYs; no orphaned processes.
• WSL, SSH, pwsh with PSReadLine, cmd and claude all launch.
• MSI built locally and its contents checked.

Not verified

• The release workflow itself: the files: signing input and the new guards. The first tagged build will exercise them.
• ARM64 and x86 at runtime. The fallback covers them.
• Day-to-day use: rendering in Claude, vim/htop-style full-screen apps, resize.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NsYm9iLc2aRnRDfV2uZRQX