[Bug] rc.7 breaks the persistent PTY shell on Windows (pid 0), node-pty 1.1.0 → 1.2.0-beta.15

[sjh9714]

症状

rc.7 之后，Windows 上的持久 PTY shell 起不来了。同一个 commit、同一套 smoke，Linux 和 macOS 全过，只有 win32 失败。

pty spawned on win32: pid 0

Error: terminal process has exited
    at LocalTerminalHandle.write (@deepseek-ai/dsh-subprocess-local/lib/index.js)

pid 0 是关键。rc.6 上同一个 smoke 打印的是真实 pid（例如 pty spawned on win32: pid 7400），Linux 和 macOS 这次也都是真实 pid（2708 / 54370）并通过。win32 拿到 0，然后第一次 write 时进程已经没了。

根因

rc.7 把 node-pty 从 ^1.1.0 提到了 1.2.0-beta.15。

@deepseek-ai/dsh-subprocess-local@0.1.0-rc.6  →  node-pty ^1.1.0
@deepseek-ai/dsh-subprocess-local@0.1.0-rc.7  →  node-pty 1.2.0-beta.15

这是 rc.6 与 rc.7 之间在这条路径上唯一的依赖变化。

实测环境

• windows-latest GitHub runner，Node 22.23.2
• 对照组同一 workflow 同一 commit，ubuntu-latest 与 macos-latest 全过
• 失败的是真实 PTY 冒烟（spawn 之后 send/read 往返），不是单元测试

单元测试看不见这个。 我这边 94 个单元测试在完整 rc.7 依赖集下全绿，tsc 也干净。只有在真实操作系统上 spawn 真实 PTY 的那一步会炸。

附带确认

顺便确认两件与本问题无关但可能有人关心的事，都是在 rc.7 发布包里看的，不是推测。

• createProcessInspector 在 win32 上仍然 throw terminal inspection is unsupported on platform win32
• this.terminalInspector ?? createProcessInspector() 这个注入座仍然在

所以这次的问题不在那条线上，是 node-pty beta 的 Windows 路径。

我这边做了什么

把 peer 范围从 >=0.1.0-rc.5 <0.2.0 收到 >=0.1.0-rc.5 <0.1.0-rc.7。对一个只服务 Windows 的插件来说，一个说「还不行」的 ERESOLVE 比一个启动即死的持久 shell 好。等这条修好会立刻放开。

如果需要更多信息（完整 workflow 日志、其它 Node 版本、或者在 1.2.0-beta.x 里二分找具体哪一版引入），我这边有 Windows CI，随时可以跑。

[sjh9714]

补一条范围说明，因为它解释了「为什么只有我一个人报这个」，对定位可能有用。

spawnTerminal 是 dsh-subprocess-local 里唯一的 PTY 入口，而它在 spawn 之前先要一个 inspector：

const inspector = this.terminalInspector ?? createProcessInspector();

在 stock 的 Windows 上，createProcessInspector() 本来就直接 throw，所以根本走不到 node-pty。也就是说 stock Windows 从来没有过能用的持久 PTY，rc.7 换 node-pty 对他们来说没有可观察的变化。

这个回归只在「已经补上 inspector」的环境里才显形。 目前会踩到的是通过 terminalInspector 注入座补 win32 实现的插件，我知道的有两个（我这个和 clearkurt/dsh-win-terminal-inspector）。所以报告量会非常少，但不代表问题小 —— 它挡住的正是 Windows 上刚刚开始可用的那条路。

顺带说，这也意味着上游修好 node-pty 这条之后，win32 的 inspector 缺口仍然独立存在，两件事互不替代。

如果需要，我这边的 windows-latest CI 可以在 node-pty@1.2.0-beta.x 里二分找出具体是哪一版引入的，把范围缩到一个 beta。说一声我就跑。

[tianhao8687]

报告抓到了版本边界，但 pid 0 在 node-pty >= 1.2.0-beta.11 上不一定表示子进程已经退出。该版本在 Windows 上延迟完成 ConPTY connect，官方使用方 VS Code 也专门处理了“spawn 后 pid 暂时为 0”：等待首个 data event 后再读取真实 pid。

当前 DSH 的 LocalTerminalHandle 构造函数 会立即固定 this.pid = terminal.pid，并立刻用该值做 process-tree identity 捕获；这与新的 node-pty 生命周期不兼容。

建议：

1. rc 热修可以先回退/锁定稳定版 node-pty@1.1.0，恢复 Windows 可用性。
2. 正式修复应让 spawnTerminal() 等待 PTY ready：在 spawn 后立即订阅 data/exit 并缓存早期数据；若 pid 已大于 0 直接完成，否则在首个 data 后重新读取 pid。退出或有限超时先发生则明确失败。
3. 在真实 pid 就绪前排队 write/inspect/signal，不能用 0 创建 rootIdentity；ready 后再构造或激活 LocalTerminalHandle，并回放缓存数据。
4. 不要只加 pid === 0 的“进程已死”判断，这会固化错误语义。

需要一个 windows-latest 原生 smoke：spawn 持久 PowerShell/cmd、等待 ready、写入唯一 token、读回、确认 pid > 0、terminate 后无残留。单元测试可模拟“初始 pid 0 → 首个 data 后真实 pid”，但不能替代该 smoke。

参考：VS Code 对 node-pty 延迟 pid 的处理。

[sjh9714]

跑完了二分，结果比我昨天写的更精确，其中一条要更正我自己的判断。

结果

windows-latest 上把 node-pty 逐版本钉住（overrides）跑同一个 PTY 冒烟，16 个并行。

node-pty	pty spawned 打印的 pid	冒烟
1.1.0	真实 pid	✅ 全过
1.2.0-beta.1 … beta.10	真实 pid	✅ 全过
1.2.0-beta.11 … beta.14	0	✅ 全过
1.2.0-beta.15	0	❌ Error: terminal process has exited

更正

昨天我把 pid 0 当成了故障的症状。不对。 pid 0 从 beta.11 就开始了，而 beta.11 到 beta.14 四个版本 pid 都是 0，却能完整跑完 send/read 往返和前台中断，一个不落。

所以这里其实是两件独立的事：

1. beta.11 起 win32 不再上报真实 pid（行为变化，但 PTY 可用）
2. beta.15 起进程在第一次 write 之前就没了（真正的回归）

对 rc.7 来说结论不变 —— 它钉的正是 1.2.0-beta.15，也就是唯一坏的那个。但对定位而言范围缩到了 beta.14 → beta.15 这一个区间，而且不要顺着 pid 0 去找，那条线索是 beta.11 留下的，和这次的崩溃不是同一回事。

对上游的建议

如果只是想让 Windows 恢复可用，1.2.0-beta.14 看起来是可以的（pid 上报仍是 0，但 PTY 功能完整）。要彻底解决还是得看 beta.14 → beta.15 之间改了什么。

我这边保留了这套矩阵（手动触发，不是 CI 门禁），如果你们想加别的组合（别的 Node 版本、别的 shell、加上 1.2.0-beta.15 的具体子路径）说一声，我跑了贴日志。

工作流和全部日志在 https://github.com/sjh9714/dsh-win32/actions/runs/32086206139