Extension console output writes over the interactive TUI

[autopeasant]

Description

A diagnostic written by an extension with console.error() during an interactive Pi session goes directly to the terminal, outside Pi's TUI renderer. It interrupts the layout and can leave the screen visually garbled until a redraw. This occurs with a minimal extension, independently of MCP.

I encountered it with pi-mcp-adapter@2.25.0 when a keep-alive stdio MCP server fails to connect. The adapter calls ui.notify(...) and then unconditionally calls console.error(...) at init.ts:322-324, so the same failure is both rendered as a Pi notification and written directly over the active TUI.

Minimal reproduction

Create logging-extension.ts:

export default function () {
  setTimeout(() => console.error("EXTENSION_DIAGNOSTIC_SENTINEL"), 3000);
}

In an interactive terminal, run:

pi --no-extensions -e ./logging-extension.ts --no-session --no-skills --no-context-files

Wait three seconds. The sentinel is printed as a raw terminal line while Pi's TUI is active. This was reproduced with @earendil-works/pi-coding-agent 0.87.1 on Linux.

MCP reproduction

With pi-mcp-adapter@2.25.0 loaded, configure a keep-alive server that exits after writing to stderr:

{
  "mcpServers": {
    "failing-stdio": {
      "command": "/bin/sh",
      "args": ["-c", "printf 'diagnostic from failing MCP server\\n' >&2; exit 23"],
      "lifecycle": "keep-alive"
    }
  }
}

On startup I observed a raw MCP: Failed to connect to failing-stdio: Connection closed (diagnostic from failing MCP server) line interleaved with the terminal control output. Pi also rendered an error notification with the same message. The raw line landed before the next TUI redraw.

Expected

Diagnostic output from a loaded extension should not write directly over an active TUI. Pi should keep the display coherent and make the diagnostic available through a supported log or notification path. The adapter can also avoid its redundant console.error when ui.notify is available; however, the minimal reproduction shows that any extension can trigger this display corruption.

I searched the Pi issue tracker for extension console.error, stderr, and TUI output reports. The closest adapter report I found is nicobailon/pi-mcp-adapter#400, which concerns a specific keep-alive refresh timeout and is closed; this startup connection-failure reproduction is distinct.

[holny]

AI-assisted content (per CONTRIBUTING.md): drafted by my local agent, reviewed and posted by me.

Reproduced with the minimal extension on 0.87.1: the sentinel is written straight to the terminal while the TUI is active.

Root cause: extensions run in-process, so console.error/console.warn from extension code goes to the host's real stderr (runner.ts itself logs through console.warn), bypassing the differential renderer and interleaving with terminal control output.

Fix direction: while the interactive TUI owns the terminal, capture extension console.* and runner diagnostic writes into a buffered log surfaced through the notification/log path instead of letting them write through to the terminal.

I'd like to implement this myself and can open a PR.

[autopeasant]

PR opened: #10050 — while ProcessTerminal is started, non-renderer writes to process.stdout/process.stderr (including console.*) are captured and surfaced through pi-captured-output.log plus a chat entry instead of landing raw over the frames. Includes regression tests and before/after PTY traces of the minimal repro.