[BUG] Settings panel re-renders at a different vertical offset on every tab switch (arrow-key navigation)

Status Open
Reported on v2.1.218
Maintainer reply None cached
Activity 1 comment · opened Jul 24, 2026

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?

Cycling tabs with the arrow keys in the settings panel opened via /usage (tabs: Status | Config | Usage | Stats) re-renders the whole panel at a different vertical position on every keypress, instead of repainting it in place. The attached recording shows it immediately: the tab strip being navigated jumps up or down the screen with each press (by as much as ~16 terminal rows), so the user's eyes have to chase it.

Two things visible in the recording that may help: the size of the jump appears to track the height of the newly shown tab's content (Config fills the screen and paginates with "47 more below"; Stats is a single loading line), and the content above the panel is affected inconsistently -- the release banner is fully visible on one tab, cut mid-line on another, and scrolled completely off screen on a third.

Input handling itself is correct -- every keypress produced exactly one tab change (verified against the recording); nothing was dropped. The issue is purely where the re-render lands.

https://github.com/user-attachments/assets/8a4ff052-dd27-4d62-8507-2466464b5b85

<img width="1564" height="938" alt="Image" src="https://github.com/user-attachments/assets/a81c5ec5-c296-4210-b5bf-24a2abbdafd4" />

What Should Happen?

The tab strip stays at a fixed screen row while navigating, with tab content rendered in a stable region below it. Content taller than the available space scrolls or paginates internally (as the Config tab already does with "47 more below"). Height differences between tabs should not translate into vertical displacement of the panel itself.

Error Messages/Logs

Steps to Reproduce

  1. Start claude (v2.1.218) in a terminal. Confirmed setup: Windows Terminal -> SSH -> Ubuntu 24.04 VM (VMware Workstation guest) -> bash. Reproduces identically with and without tmux (verification matrix in Additional Information).
  2. Run /usage to open the settings panel with tabs Status | Config | Usage | Stats.
  3. Press Right Arrow repeatedly to cycle through the tabs.
  4. Watch the tab strip: after each press it lands on a different terminal row. Reproduces on every pass (the recording shows two full cycles).

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.218 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Windows Terminal

Additional Information

  • Model in use: Fable 5 (xhigh effort) on a Claude Max subscription (not listed in the Model dropdown above).
  • Environment: Windows Terminal -> SSH -> Ubuntu 24.04 VM (VMware Workstation guest), bash. The recording was captured inside tmux (TERM=tmux-256color, default status bar visible).
  • tmux ruled out at every level -- the bug reproduces identically: (1) inside tmux; (2) in a plain SSH session with no tmux in the process ancestry (verified with pstree: systemd -> sshd -> bash); (3) with the TMUX environment variable explicitly unset (env -u TMUX claude). Tested under both TERM=tmux-256color and TERM=xterm-256color.
  • Possibly related, not duplicates: #29937 (Ink render-state corruption under tmux), #37283 (tmux flicker, missing synchronized-output) -- though unlike those, this issue is not tmux-specific.
  • Attached: screen recording (17 s, two full tab cycles) and a 4-up still figure marking the tab-strip position in each state, for skimming without playing the video.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗