fix: PTY proxy for local mode stdin corruption

[mfazekas]

After local→remote→local mode switch, Node.js children spawned with stdio:'inherit' stop receiving stdin.

Fix: spawn local-mode children via node-pty in their own PTY (child never inherits parent's fd 0), and give Ink a separate /dev/tty fd so it never touches process.stdin.

Investigation details

Native binaries (e.g. cat) using raw read() are unaffected — only Node.js children break.

The remote mode code and Ink both manipulate process.stdin (flowing mode, setEncoding, setRawMode) between child spawns. After cleanup (pause(), removeAllListeners()), something in the libuv TTY handle state remains dirty, preventing subsequent Node.js children from reading stdin.

E2e tests reproducing the issue: test/pty-proxy-e2e (test file)

Code that touches process.stdin between spawns:

• claudeRemoteLauncher.ts:62-66
• Ink App.tsx:161 (v6.6.0)

Fixes #527
Fixes #423

[speakman]

Hey @mfazekas! Found the root cause of the PTY exhaustion on macOS.

TL;DR: node-pty v1.1.0 has an off-by-one bug in pty_posix_spawn() that leaks 1 PTY master fd per pty.spawn() call. The upstream fix is in microsoft/node-pty#882 (merged 2026-01-28), available in 1.2.0-beta.9+.

I opened a PR against your branch with the fix: mfazekas#1

Changes:

1. Upgrade node-pty from 1.1.0 → 1.2.0-beta.11 (includes the leak fix)
2. Fix abort handler to kill the process group (-pid, SIGTERM) instead of just the launcher PID (SIGHUP), so the Claude binary grandchild is also terminated

The bug is in the low_fds cleanup loop in src/unix/pty.cc — it uses for (; count > 0; count--) which skips low_fds[0] when count == 0 (the normal case). The fix changes it to for (size_t i = 0; i <= count; i++).