Summary
1.2.0-beta.15 breaks persistent PTY sessions on Windows. The pty spawns, and the process is already gone by the first write:
Error: terminal process has exited
at LocalTerminalHandle.write (...)
1.2.0-beta.14 is fine. Every earlier version I tested is fine. This is a single-version regression.
Bisect
Same smoke, same commit, windows-latest GitHub runner, Node 22.23.2, one job per version, node-pty pinned through an npm overrides entry so the copy under test is the one actually imported.
| version |
pid reported at spawn |
send/read round trip + foreground interrupt |
1.1.0 |
real pid |
pass |
1.2.0-beta.1 … beta.10 |
real pid |
pass |
1.2.0-beta.11 … beta.14 |
0 |
pass |
1.2.0-beta.15 |
0 |
fail, process exited before the first write |
Full logs: https://github.com/sjh9714/dsh-win32/actions/runs/32086206139
Two separate changes, and the second is the regression
I want to flag this because the obvious lead is a red herring.
pid 0 at spawn starts at beta.11, not at beta.15. But beta.11 through beta.14 complete the whole smoke with pid 0, including a send/read round trip and a SIGINT delivery that returns exit code 130. So pid 0 on its own is not the fault, and anyone bisecting toward the pid change will land four versions early.
The actual break is confined to beta.14 → beta.15.
What the smoke does
Spawns a shell in a pty, writes a command that stores state, reads it back in a later write to prove the session persisted, then sends \x03 and checks the foreground command exits 130. It is a plain consumer of the public API. Nothing here reaches into internals.
Why this may not have been reported yet
The path only opens up on Windows once the host supplies a terminal process inspector, which the consumer I maintain does; without one the spawn is refused earlier for unrelated reasons and node-pty is never reached. So the population that can observe this is small, but 1.2.0-beta.15 is what the current release of that host pins, so it is the version its Windows users get.
Happy to run more combinations on the same matrix (other Node versions, other shells, a narrower probe inside beta.15) if that helps localize it. Just say which.
Summary
1.2.0-beta.15breaks persistent PTY sessions on Windows. The pty spawns, and the process is already gone by the firstwrite:1.2.0-beta.14is fine. Every earlier version I tested is fine. This is a single-version regression.Bisect
Same smoke, same commit,
windows-latestGitHub runner, Node 22.23.2, one job per version,node-ptypinned through an npmoverridesentry so the copy under test is the one actually imported.1.1.01.2.0-beta.1…beta.101.2.0-beta.11…beta.141.2.0-beta.15Full logs: https://github.com/sjh9714/dsh-win32/actions/runs/32086206139
Two separate changes, and the second is the regression
I want to flag this because the obvious lead is a red herring.
pid 0at spawn starts atbeta.11, not atbeta.15. Butbeta.11throughbeta.14complete the whole smoke withpid 0, including a send/read round trip and aSIGINTdelivery that returns exit code 130. Sopid 0on its own is not the fault, and anyone bisecting toward the pid change will land four versions early.The actual break is confined to
beta.14 → beta.15.What the smoke does
Spawns a shell in a pty, writes a command that stores state, reads it back in a later write to prove the session persisted, then sends
\x03and checks the foreground command exits 130. It is a plain consumer of the public API. Nothing here reaches into internals.Why this may not have been reported yet
The path only opens up on Windows once the host supplies a terminal process inspector, which the consumer I maintain does; without one the spawn is refused earlier for unrelated reasons and node-pty is never reached. So the population that can observe this is small, but
1.2.0-beta.15is what the current release of that host pins, so it is the version its Windows users get.Happy to run more combinations on the same matrix (other Node versions, other shells, a narrower probe inside
beta.15) if that helps localize it. Just say which.