Potential terminal instability and resize loops caused by TerminalCapabilityManager's ANSI probing

[Gong-Mi]

Description

Observed severe terminal instability and 'resize loops' on Android (Termux) and potentially other TTY environments. The terminal bounces between dimensions (e.g., 43x75 and 46x75) multiple times per second, as documented in .

Root Cause Analysis

The issue appears to stem from the recent implementation in (Commit ).

To avoid a stray 'm' character on certain terminals, the manager now wraps capability queries in:

• (HIDDEN_MODE)
• (CLEAR_LINE_AND_RETURN)
• (RESET_ATTRIBUTES)

Identified Risks

1. Terminal State Leakage: If the process crashes or is interrupted (e.g., SIGINT) after sending but before , the user's terminal becomes 'invisible' and effectively unusable until a manual is performed.
2. Synchronous I/O Interference: Using bypasses the React/Ink rendering lifecycle. In environments like Termux, this synchronous burst of ANSI sequences can trigger layout recalculations that lead to infinite resize loops.
3. Performance Bottleneck: The handler performs (N^2)$ string concatenation and runs 5 complex regex matches on the entire history buffer for every data chunk received during the 1-second probing window.
4. Startup Latency: Terminals that do not respond to (e.g., IDE internal terminals, mock environments) are forced to wait for the full 1000ms timeout on every startup.

Evidence (pty_history.log)

[2026-02-13 18:21:10] 46x75 | 1200px x 1472px
[2026-02-13 18:21:10] 43x75 | 1200px x 1376px
[2026-02-13 18:21:10] 46x75 | 1200px x 1472px
... (repeated dozens of times per second)

Questions for Maintainers

• Is the cosmetic fix for a single 'm' character worth the risk of hijacking the user's terminal state or causing rendering loops?
• Should we consider a more robust state-machine based parser for TTY responses instead of cumulative string matching?
• Can we gate this probing behind a more strict TTY check or disable it for known problematic environments?