[Bug]: Terminal UI corrupts and gets permanently stuck when scrolling in Neovim

[cedi]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. Open a project in T3 Code and open its integrated Terminal panel.
2. Inside the terminal, launch nvim against any file.
3. Scroll within Neovim (e.g. Ctrl-D/Ctrl-U, mouse wheel, or j/k repeated quickly) so it repaints the screen rapidly.
4. Repeat scrolling for a bit. Intermittently, mid-scroll, the terminal canvas will render a corrupted, mixed-up frame.

Expected behavior

The terminal should always show either the previous complete frame or the next complete frame from Neovim — never a mixture of the two — and should recover on its own even if a frame update is somehow left unterminated.

Actual behavior

The terminal canvas occasionally freezes into a torn/garbled frame (parts of the old screen and parts of the new screen mixed together) while scrolling in Neovim. Once this happens, the UI does not self-correct: further input and rendering stay visually broken until the user closes the Terminal panel and reopens it, recreating the terminal session from scratch.

Impact

Major degradation or frequent failure

Version or commit

main @ be7d35a

Environment

Reproduces on web/desktop (Chromium-based Ghostty WASM renderer) and Android's native Ghostty JNI bridge; not reproducible on iOS, which renders through Ghostty's native renderer rather than a custom dirty-row snapshot loop.

Logs or stack traces

Screenshots, recordings, or supporting files

Pasted image 20260821130848.png

Workaround

Close and reopen the Terminal panel/tab to recreate the terminal session, which resets the renderer state.

[cedi]

From my investigation:

Neovim brackets each repaint with DEC private mode 2026 (\e[?2026h ... \e[?2026l, "synchronized output"), which tells a terminal emulator to buffer updates and only redraw once the closing sequence arrives. T3 Code's Ghostty-based renderer (web apps/web/src/terminal/ghostty/{core,surface}.ts, and the equivalent Android native path) instead reads and clears Ghostty's per-row dirty state on every animation frame regardless of whether a synchronized update is still open. Because PTY output arrives in arbitrarily-sized chunks, a render tick can land exactly between the open and close sequences, snapshotting (and clearing) only part of the new frame.
The result is a permanently mixed frame: since the dirty bits for the already-rendered rows were cleared, nothing marks them dirty again, so the corruption never repairs itself without recreating the terminal.