Summary

hermes --tui can still visually corrupt after aggressive terminal window resizing. The visible symptom is scattered/corrupted glyphs after dragging the terminal size back and forth quickly.

This appears to be the same general resize/desync class previously addressed by:

• fix(ui-tui): heal post-resize alt-screen drift (#14640)

But the artifact still seems reproducible in at least some host terminals / resize patterns.

Observed behavior

• Start hermes --tui
• Resize the terminal window rapidly for a few seconds
• The screen can end up with stale letters / broken layout instead of a clean repaint

Expected behavior

A rapid resize burst should always converge to a clean frame with no stale glyphs left behind.

Relevant code / evidence

Current code already contains resize-healing logic:

• ui-tui/packages/hermes-ink/src/ink/ink.tsx
  • handleResize()
  • resetFramesForAltScreen()
  • needsEraseBeforePaint
  • post-resize resizeSettleTimer
• ui-tui/packages/hermes-ink/src/ink/log-update.test.ts
  • contains comments/tests around the existing "scattered letters after rapid resize" artifact

The current unit coverage looks helpful but still limited to diff/contract invariants. It does not yet prove that a resize burst plus host-side reflow always heals the physical terminal state.

Likely gap

There may still be a race between:

• host terminal reflow during repeated resize events
• the logical previous frame tracked by Ink
• the deferred settle repaint after the burst

So this may need either:

1. stronger resize-burst healing logic, or
2. a higher-level regression harness that simulates repeated resize bursts against the real PTY/TUI path rather than only screen-diff contracts.

Suggested next step

• add a regression test around repeated resize bursts / stale physical terminal drift, ideally at the PTY/integration level if unit tests cannot model the host behavior reliably
• re-check whether the settle repaint should run more defensively for some resize sequences / terminal hosts

Notes

I’m opening this as a follow-up issue because the existing codebase clearly knows about this class of bug, but the artifact still appears in real use.