[BUG] Changing `tui` to fullscreen under a running classic-renderer session cuts off the bottom of a long prompt (typed text is invisible)

Status Open
Reported on v2.1.288
Maintainer reply None cached
Activity 0 comments · opened Oct 4, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report
  • [x] I am using the latest version of Claude Code

What's Wrong?

If the tui setting becomes "fullscreen" while a session that started with the classic renderer is still running, that session is left half-switched. It stays on the main screen (no alternate screen), but the prompt area starts obeying a height cap of about half the terminal, and whatever is below the cap is cut off instead of scrolled.

With a multi-line draft taller than that, the frame is redrawn without the draft's last line(s), the prompt box's bottom border and the footer. Typing on the cut-off line moves the cursor but draws nothing, so it looks like typing black on black. Lines higher up in the same draft edit normally.

In a 174x59 terminal the cut is after the top border plus 27 draft lines: with a 28-line draft, line 28, the bottom border and the footer are gone.

Short prompts render normally, so nothing tells you the session needs a restart until you paste something long.

What Should Happen?

A running session should either keep its renderer and layout as they were until it is restarted (maybe with a notice that tui changed), or switch completely. The line the cursor is on should never be dropped from the frame.

Error Messages/Logs

No errors. A pty recording (script) of the session shows no alternate-screen (?1049h) or scroll-region sequences after the change, only a re-render that erases the rows where the bottom border and footer were. A character typed on the last line produces only cursor movement.

Screen before the change (draft of 26 lines plus two empty ones, Q typed on the last line):

  line 25 of a long prompt
  line 26 of a long prompt

  Q
──────────────────────────────────────────────────────────────────────
  ⏵⏵ auto mode on (shift+tab to cycle)

After the change, same draft, nothing typed or deleted (rows below are empty to the end of the screen):

  line 24 of a long prompt
  line 25 of a long prompt
  line 26 of a long prompt

Steps to Reproduce

  1. Have "tui": "fullscreen" in ~/.claude/settings.json. In a scratch project, create .claude/settings.local.json with {"tui": "default"} and start claude there in a terminal about 60 rows tall. It starts with the classic renderer.
  2. Paste a 26-line text that ends with two newlines, then paste the same text again to expand it ("paste again to expand"). Type Q: it shows on the last line, with the border and footer below it.
  3. While the session is running, replace the contents of .claude/settings.local.json with {}, so the effective tui becomes fullscreen.
  4. Within a few seconds the frame is redrawn: an extra blank row appears above the logo, and the draft's last line, the bottom border and the footer disappear. Type more characters: nothing shows.
  5. Put {"tui": "default"} back: the border and footer return, along with everything typed blind.

I first hit this the other way round: a script added "tui": "fullscreen" to ~/.claude/settings.json while a session started without that key (classic renderer, 2.1.288) was running. That session behaved the same until it was restarted.

Workaround: restart the session (/exit, then claude --resume).

My guess at the cause: part of the layout reads settings.tui live, while the renderer and the prompt's scrolling window are fixed at startup. A session started in fullscreen handles the same draft fine: it shows a 24-line window that follows the cursor.

Claude Model

Opus

Is this a regression?

I don't know

Claude Code Version

2.1.289 (also 2.1.288)

Platform

Anthropic API

Operating System

macOS 27.0.1, Apple silicon

Terminal/Shell

Other: herdr 0.9.3 (terminal multiplexer, TERM=xterm-256color), 174x59, zsh

View original on GitHub ↗