pastilhasandClaude Opus 4.8
b92e8dffad
the pty sidecar registered `term.onData` with the socket that happened to be live when the session was created. officer is a pm2 peer that restarts constantly, and every restart hands this process a brand new socket, so every pre-existing session went on writing to a closed one — where sendJson's readyState check dropped it silently. the shell survived and still accepted input, because input arrives on the new socket, but nothing ever came back. you typed and the terminal sat there. the only way out was to close the panel, which orphaned the shell. sendJson now reads the module-level socket at send time instead of taking one as an argument, so there is no socket to capture and go stale. that is the whole fix. the scrollback replay on re-attach becomes its own event, pty:replay -> 'replay' on the browser socket. it used to arrive as ordinary output, which was fine for a page load (fresh xterm) but not for a restart: the browser keeps its terminal, so replaying blind printed a second copy of everything still on screen. marked as history, Terminal.tsx resets and rebuilds from the sidecar's 50KB buffer instead. it also stays out of the `output` branch so it cannot re-trigger the command / initial-input logic that scrapes output for a sentinel. added an integration test, because this is a reconnect bug and nothing short of an actual reconnect proves it: it stands up a fake registration socket, runs the real sidecar against it, echoes into a real shell, kills the socket, rebinds the same port the way pm2 does, and asserts output still flows. verified it fails against the old sendJson (times out after 15s waiting for the post-restart echo) and passes in ~400ms with the fix. it never touches the running officer — the sidecar dials API_URL, overridden per spawn. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>