Bug Description

After the TUI gateway crashes and restarts (specifically the "broken stdout pipe" scenario), the TUI input box gets flooded with raw ANSI escape sequences. These are terminal control codes that should go to stdout (for rendering the TUI UI), but leak into stdin (the user input stream), causing garbage to appear in the input field as if someone is typing it.

📸 Screenshot: [screenshot pending — see comment below]

The injected content looks like:

102;71M5;104;62M5;106;60M61M35;22;72M35;21;71M35;17;70MM35;10;70M;70M5;70M;85;72M2;48;72M68m1M35;17;71M[I35;27;3M5;26;8M;12M;13M7;16M;27;18M;27;20M;28;21M8;23M1M29;36M5;28;38M;28;39M5;28;40M5;24;47M54M35;13;55M6M35;10;63M5;9;66M35;8;68M1M[O[I7;57M35;21;67M35;22;70M23;70M;68MMM

These are recognizable as ANSI CSI sequences (e.g., ESC[35m = magenta text, ESC[I = cursor up, ESC[O = function key).

Root Cause Analysis

The TUI gateway communicates with the terminal via stdin/stdout pipes:

• stdout → TUI rendering (ANSI escape sequences for colors, cursor positioning, layout)
• stdin → User keyboard input

When the stdout pipe breaks (crash log: startup write failed (broken stdout pipe before first event)), the isolation between the two streams is compromised, and rendering output leaks into the input stream.

After the gateway restarts, the TUI reads the leaked ANSI data from stdin as if it were user keystrokes, causing the input box to fill with garbage.

Environment

• Hermes: v0.14.0 (77 commits behind main)
• OS: macOS 14.8.7 (Sonoma)
• Terminal: Terminal.app
• Python: 3.11.4 (Framework)

Steps to Reproduce

The exact trigger isn't deterministic, but the pattern observed:

1. Run hermes --tui normally
2. At some point the TUI gateway crashes with startup write failed (broken stdout pipe before first event)
3. Gateway auto-restarts (launchd RunAtLoad: true)
4. After restart, the TUI input box shows escaped ANSI sequences
5. Multiple TUI instances may be running (PID 47400 + 48473 in observed case)

Log Evidence

tui_gateway_crash.log:

=== gateway exit · 2026-05-19 11:10:21 · reason=startup write failed (broken stdout pipe before first event) ===

=== unhandled exception · 2026-05-19 11:10:21 ===
Traceback (most recent call last):
  File ".../tui_gateway/entry.py", line 224, in main
    _log_exit("startup write failed (broken stdout pipe before first event)")
BrokenPipeError: [Errno 32] Broken pipe

Timeline from agent.log:

Workaround

hermes gateway restart
# Then close all TUI sessions and reopen with: hermes --tui

Mitigation Suggestion

When the TUI gateway detects a broken stdout pipe and restarts, it should flush/discard any buffered stdin data before re-entering the input loop. This would prevent stale rendering output from being injected into the new session's input stream.