Thanks for taking the time to put this together. Unfortunately I don't think we can take this as-is — there are a couple of architectural blockers I should explain so the work isn't wasted.

run_command is invoked by the model, not by a human at the terminal. There's no one to type a sudo password or answer npm init's prompts — the agent loop reads the captured output and decides the next step. So "make interactive commands work" isn't quite the right goal for this tool; the right answer for sudo / ssh is for the model to run them in non-interactive form (sudo -n, ssh -o BatchMode=yes, npm init -y) and surface a clear error when credentials are actually required.

Ink owns stdin/stdout. Reasonix's UI is an Ink TUI, which keeps process.stdin in raw mode and renders on process.stdout. The PTY path here calls process.stdin.setRawMode(true) and attaches its own data listener while Ink is also reading keys — they'll fight over keystrokes — and it writes raw PTY bytes straight to process.stdout, which will corrupt whatever Ink is currently drawing. Any "let the user drive the child process" design has to negotiate with Ink (suspend rendering, hand over the TTY, restore on exit), not bypass it.

A few smaller things I'd flag regardless:

• opts.signal is dropped on the PTY path, so the parent loop can't cancel it.
• needsPty uses startsWith on the raw string — sudoku matches sudo, and the prefix list will miss most real interactive tools.
• Output truncation keeps the tail; the existing exec path keeps the head with a [… truncated …] marker. The model expects the latter shape.
• node-pty is a native dep with an install script (node-gyp). Adding it raises the install-failure surface, especially on Windows without Build Tools — needs a stronger justification than the current use case.
• The toLocaleString("en-US") change in src/loop/errors.ts is unrelated to PTY. If you'd like to land that on its own I'm happy to take it as a separate PR.

Going to close this one. Appreciate the contribution — if you're interested in the non-interactive-flag detection angle (helpful error message when a command would have prompted), that'd be a welcome follow-up.