[BUG] `/tui fullscreen` (flicker-free renderer): typed input is not echoed in the prompt until submit. Input is received but never drawn

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

After switching the renderer with /tui fullscreen, characters typed into the prompt are not rendered as you type. The input is still being received —
pressing Enter submits exactly what was typed — but nothing appears on screen until a submit (or certain other events) forces a repaint. The prompt looks
frozen/unresponsive even though keystrokes are landing.

What Should Happen?

Expected: characters appear in the prompt as you type.
Actual: the prompt does not update. Typing produces no visible echo. Pressing Enter submits the (invisible) typed text — confirming the input was
captured the whole time — and the submit-driven repaint makes rendering recover.

Error Messages/Logs

N/A

Steps to Reproduce

1. Start claude in a terminal.
2. Run /tui fullscreen.
3. Type several characters into the prompt.

Claude Model

Not sure / Multiple models

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

latest

Platform

Anthropic API

Operating System

Other

Terminal/Shell

Other

Additional Information

### Key characterization

• It's a render/repaint bug, not an input bug. Input is received and buffered correctly (it submits on Enter); it simply isn't drawn.
• The fullscreen renderer does repaint in response to some events (submitting; also observed: making a mouse text-selection), but not on keystroke

input. A plain refocus click does not trigger a repaint. This suggests the renderer isn't scheduling a frame in response to stdin keystrokes.

• /tui default (classic renderer) does not exhibit this; only the fullscreen/flicker-free renderer.

### Scope
Reproduces in two terminal stacks that share essentially none of their rendering/input plumbing:

• a native Windows console (PowerShell in conhost / Windows Terminal — native text rendering), and
• xterm.js (the DOM/JavaScript terminal emulator that powers VS Code's integrated terminal and most web-based terminals).

Same symptom in both — the prompt receives no repaint. A DOM-based emulator and a native console failing identically points at the fullscreen renderer emitting
no frame on keystroke, rather than either terminal's handling of it.

### Possible clue (unconfirmed — may be a red herring)
In a terminal capture, the fullscreen renderer repeatedly emits XTVERSION (ESC [ > 0 q) — 18 times in one session — and no other capability queries (no
DSR/DA/DECRQM). If the renderer re-queries terminal identification and degrades its repaint scheduling when it gets no DCS > | … ST reply, that may be
related.

### Workaround
Use /tui default.