Windows ConPTY: unhandled 'error' event on conout/conin sockets + re-throw in error handler kills the embedding host

Start in lib/windowsPtyAgent.js around the _outSocket and _inSocket construction, then follow the existing _failPtyConnection path. Read the socket error handling in lib/windowsTerminal.js and check how ready_datapipe and agent.onError lead to cleanup. Done means broken ConPTY pipes no longer produce an uncaught exception or kill the embedding host; the reported verification used node --check.

Summary

Windows ConPTY (named pipe) sockets created in WindowsPtyAgent have no 'error' listener at construction time, and WindowsTerminal's error handler re-throws non-EIO errors from inside the 'error' event. Both paths turn a broken ConPTY pipe into an uncaught exception that kills the whole host process (observed twice, e.g. exit code 1 with the classic Unhandled 'error' event dump and once with 0xC0000005).

Version: 1.2.0-beta.15 on Windows (Node v24.14.0), consumed via dsh-subprocess-local.spawnTerminal.

Repro / trigger

Any long-running persistent PTY whose ConPTY pipe breaks while the host is alive:

• child process tree killed externally (e.g. taskkill /T, cleanup tools, watchdog scripts)
• machine sleep/wake invalidating the pipe
• connection timeout / worker failure before ready_datapipe

Once the pipe breaks, the next socket read/write fails with Error: read UNKNOWN (errno: -4094, code: 'UNKNOWN') and the whole embedding process dies.

Evidence

Host-process stderr captured at crash:

node:events:486
      throw er; // Unhandled 'error' event
      ^

Error: read UNKNOWN
    at Pipe.onStreamRead (node:internal/stream_base_commons:216:20)
Emitted 'error' event on Socket instance at:
    at emitErrorNT (node:internal/streams/destroy:170:8)
    at emitErrorCloseNT (node:internal/streams/destroy:129:3)
    at process.processTicksAndRejections (node:internal/process/task_queues:90:21) {
  errno: -4094,
  code: 'UNKNOWN',
  syscall: 'read'
}

Node.js v24.14.0

Root cause (code)

lib/windowsPtyAgent.js (constructor, ~lines 56-93):

this._outSocket = new net_1.Socket();
...
this._outSocket.on('connect', function () {
    _this._outSocket.emit('ready_datapipe');
});
var inSocketFD = fs.openSync(term.conin, 'w');
this._inSocket = new net_1.Socket({ fd: inSocketFD, readable: false, writable: true });

• _outSocket: the 'error' listener is only attached later in windowsTerminal.js inside the ready_datapipe callback — before that fires, an error on this socket is unhandled → process crash.
• _inSocket: never gets an 'error' listener at all → any write/read error = Unhandled 'error' event → process crash.

lib/windowsTerminal.js (~lines 89-105):

_this._socket.on('error', function (err) {
    _this._close();
    if (err.code) {
        if (~err.code.indexOf('errno 5') || ~err.code.indexOf('EIO')) return;
    }
    // Throw anything else.
    if (_this.listeners('error').length < 2) {
        throw err;   // throw from inside an 'error' handler = uncaught exception
    }
});

Suggested fix

1. Attach 'error' handlers on both sockets immediately after creation in WindowsPtyAgent, funneling into the existing _failPtyConnection path (which fires onError → terminal exit → graceful cleanup).
2. Remove/replace the throw err in WindowsTerminal — errors already flow via agent.onError → exit; re-throwing from an 'error' listener is a process-killer for embedding consumers.

I applied exactly these two changes locally (verified with node --check) and the host process no longer dies on the broken-pipe path.