[BUG] /tui fullscreen clips shell-details footer and output box without tmux (plain iTerm2)

Reproduced on Windows 11 + ConPTY in default /tui mode as well — fullscreen mode is not required, so the trigger appears to be more general than the fullscreen setting: whenever the in-progress turn's dynamic region (turn transcript + spinner + expanded shell details + input box + status bar) exceeds the terminal height, the bottom of the frame is clipped — the input box, status bar and the panel footer never render. Because the repaint style produces no scrollback, the clipped content is also unreachable by scrolling.

Evidence from a raw PTY byte capture (xterm.js 6 host via node-pty 1.1.0 / ConPTY, PowerShell 5.1):

• Clicking "1 shell" in the status bar during an in-progress turn at 29 rows: the repaint frames only ever address rows 1–29, and the input-box / status-bar text (⏸ manual mode on, shortcut hints) is entirely absent from the byte stream — it is never emitted, not merely painted off-screen. The terminal's buffer never grows beyond screen height (baseY stays 0), so there is no scrollback to recover the clipped part.
• The identical scenario at 59 rows renders completely: the output box clamps itself ("Showing 9 lines") and the footer ("← to go back · Esc/Enter/Space to close · x to stop") is visible. Terminal height is the only variable between the two runs.
• Host-side factors ruled out: Windows inbox conhost ConPTY vs. bundled OpenConsole 1.23.251008001 (useConptyDll: true) behave identically, and faking TERM_PROGRAM=vscode makes no difference.

Expected behavior matches the OP: the expanded shell-details view should clamp itself into the available rows (or take over the viewport) with the footer pinned to the bottom row and internal scrolling for the output box.

Environment: Claude Code 2.1.215, Windows 11 Pro build 26200, node-pty 1.1.0 (ConPTY), xterm.js 6, PowerShell 5.1.

Reproduced on Windows 11 + VS Code integrated terminal + Windows Terminal — with a precise trigger condition

Environment

• OS: Windows 11 Pro 10.0.26200
• Terminal: VS Code integrated terminal (primary) + Windows Terminal (secondary, both via ConPTY)
• Claude Code: v2.1.223
• TUI mode: fullscreen (also reproduced in default mode, but fullscreen is worse)
• Session: long conversation with 10 tasks in the task list + 2 workflows running in background (each workflow dispatches 10 sub-agents running ping -n 300 127.0.0.1)

Problem

When a task list (10 tasks) and background tasks (2 workflows + 20 sub-agents) coexist in the same session, the TUI bottom bar intermittently breaks:

1. Background task navigation invisible: Arrow-down from the input box to navigate background tasks (shells/workflows/sub-agents) shows nothing — no indication of which item is selected. Can only blind-select (press Enter and hope).
2. Task list sticky: Scrolling the conversation up/down does NOT scroll the task list — it stays pinned, reducing the visible conversation area.
3. Shell/workflow details clipped: After selecting a workflow and pressing Enter, the sub-agent status section (shown below the input box) is cut off at the bottom — the bottom portion is missing, as if the frame is taller than the terminal.

Key finding — precise trigger condition

The bug is triggered by assistant output rendering and recovers when the user sends a message:

• User sends a message → TUI renders correctly: tasks scroll, background nav visible, details not clipped.
• Assistant responds (text output rendered) → TUI breaks: background nav invisible, task list sticky, details clipped.
• User sends next message → Recovers again: correct rendering.
• Assistant responds again → Breaks again.

This cycle is reproducible: every assistant reply triggers the break, every user input recovers it. The pattern is consistent across both VS Code terminal and Windows Terminal.

Interpretation

This matches the issue description: "whenever the in-progress turn's dynamic region (turn transcript + spinner + expanded shell details + input box + status bar) exceeds the terminal height, the bottom of the frame is clipped."

The assistant output appears to be the element that pushes the dynamic region past the terminal height — when the assistant's text is rendered, the total height (assistant output + task list + background task nav + input box + status bar) exceeds the available rows, and the bottom bar (nav + details) gets clipped. When the user input is rendered, the layout recalculates with a different height profile, and everything fits.

Test setup for reproduction

1. Create 10 tasks (any pending tasks via TaskCreate).
2. Launch 2 workflows, each dispatching 10 sub-agents running a long command (e.g., ping -n 300 127.0.0.1 with Bash timeout 360000) — this gives 2 workflows + 20 sub-agents in the background task list.
3. Send a message → assistant replies → observe the TUI break (nav invisible, task list sticky, details clipped).
4. Send another message → observe recovery.
5. Repeat step 3-4 to confirm the cycle.

Version note

v2.1.223 improved the situation compared to earlier versions (the TUI sometimes works correctly in fullscreen with task list + background tasks), but the bug is not fully fixed — it's intermittent and triggered by the assistant-output rendering condition described above. In default (classic renderer) mode, the issue is less severe (navigation works, but the input box scrolls with the conversation instead of staying pinned).

Related issues

• #84228 (input box overflow when todo/task widget visible) — related to task list consuming bottom-bar space
• #39968 (TaskList + background tasks interference) — closed for inactivity, not fixed; this report confirms the same interference pattern persists in v2.1.223

Confirmed / reproduced on 2.1.233 (Linux, tmux, wide-short windows like 210×14 and 210×35).

With "tui": "fullscreen", backgrounding while true; do date; sleep 1; done and opening it from /tasks: the shell-details panel renders inline below the transcript instead of taking over the viewport, the output box gets only leftover height (I saw the exact same "Showing 9 lines"), and at 14 rows the "← to go back · Esc/Enter/Space to close · x to stop" footer is clipped below the visible screen.

Two notes from my runs:

• On Linux the default TUI mode rendered the same clipped layout, so it may not be fullscreen-specific everywhere.
• The output box did live-update for me (timestamps kept advancing, with a few seconds of lag), so I couldn't reproduce the frozen-snapshot part — if you still see it stuck on the latest version, that detail would be worth a separate note.

The layout/clipping problem is real and we're tracking it.

🤖 Generated with Claude Code