Header/title duplicates repeatedly when the terminal is narrowed

[wilversings]

Header/title duplicates repeatedly when the terminal is narrowed

Summary

When the terminal window is made narrower, the top chrome of the TUI (the ✻ Claude title, the Code / Chat / Scheduled tab row, and the / search… line) gets redrawn on top of the old frame instead of replacing it, so it stacks up multiple copies. Dragging a window/pane smaller (which fires many resize events in a row) produces several duplicated header blocks; the more you shrink, the more copies pile up.

Steps to reproduce

1. Run claude-sessions in a terminal with at least one project that has sessions.
2. Grab the window (or tmux pane) edge and drag it narrower, or run resize-window/SIGWINCH down to ~24–40 columns.
3. Observe the header/title/tab/search block appearing two or more times, stacked vertically.

Reproduced on main (v2.5.0), Node 22/24, inside a clean Fedora container, rendering through tmux 3.7 (a faithful terminal emulator). Not tmux-specific — any terminal reflows wrapped lines the same way.

Expected vs actual

• Expected: on resize the UI redraws once, cleanly, at the new width.
• Actual: each narrowing step leaves the previous header rows on screen and draws a fresh copy below them.

Evidence

Likely cause

Ink erases the previous frame by counting the number of logical lines it last emitted, then redraws. When the terminal gets narrower, lines that previously fit on one row now wrap onto several physical rows in the terminal. Ink's erase count no longer matches the physical rows the old frame actually occupies, so the stale (wrapped) rows are not cleared and the new frame is painted underneath them. Every SIGWINCH during a drag repeats this, so the header multiplies.

The app renders a fixed-width outer box (<Box … width={stdout.columns}> in src/index.tsx) and relies on Ink's built-in re-render on resize; there is no explicit resize/clear handling, which is what lets the artifact accumulate.

Fix estimate — Low (small, localized change)

This is a well-known Ink resize class of bug and the fix is a few lines in src/index.tsx, no architectural change:

• Add a stdout "resize" handler that clears the screen (e.g. write \x1b[2J\x1b[3J\x1b[H) before Ink repaints, or
• Render into the alternate screen buffer (fullscreen mode) so reflow can't leave scrollback residue.

Main cost is verification across a couple of terminals (native terminal, tmux) and both grow/shrink directions — call it a half-day including testing.

I'm happy to open a PR implementing the resize-clear (or fullscreen) approach with a short before/after check across terminals — just let me know which direction you'd prefer.

[kud]

Thanks for this. The repro steps and the screenshots made it easy to follow.

One thing worth flagging before you start, because it changes where the fix goes: both of the approaches you suggest are already in v2.5.0.

The TUI already renders into the alternate screen buffer. src/index.tsx writes \x1b[?1049h before each render(<App />) and restores with \x1b[?1049l on exit. And v2.5.0 pins ink@7.1.0, which ships a clear-on-narrow handler that does what your first option describes:

resized = () => {
  const currentWidth = getWindowSize(this.options.stdout).columns;
  if (currentWidth < this.lastTerminalWidth) {
    // We clear the screen when decreasing terminal width to prevent duplicate overlapping re-renders.
    this.log.clear();
    this.lastOutput = '';
    this.lastOutputToRender = '';
  }
  ...

So you reproduced this with both mitigations already active. That is useful, because it puts the cause one level below either of them.

I think it is this. log.clear() erases with ansiEscapes.eraseLines(previousLineCount), and previousLineCount comes from str.split('\n').length, so it counts logical lines. eraseLines(n) expands to an eraseLine plus cursorUp() repeated, walking up exactly n physical rows. Those two numbers agree only while nothing wraps. Narrow the terminal, one long line becomes two physical rows, and the erase walks up fewer rows than the old frame actually occupies. The remainder stays on screen and the new frame is painted under it. Ink's own mitigation under-erases in exactly the case it was added for, which is why alt-screen plus 7.1.0 still leaves you with stacked headers.

If that holds, the direction I would prefer:

1. Clear on narrowing in a way that does not depend on a line count. We are already in the alternate buffer, so a full \x1b[2J\x1b[3J\x1b[H costs nothing there and cannot under-erase. This is your suggestion, just reaching past the counting instead of relying on Ink's version of it.
2. Remove the wrapping that breaks the arithmetic in the first place. The outer box is <Box flexDirection="column" paddingY={1} width={stdout.columns}>, and long session labels can exceed that width. With wrap="truncate" on the text that can overflow, logical lines and physical rows stay equal and Ink's own maths is correct again.

(1) fixes what you are seeing now. (2) is what keeps it from returning the next time a label gets long.

A PR would be very welcome, and thank you for offering. Your setup is also better placed than mine for checking it: I am on macOS, and everything above comes from reading Ink 7.1.0's source rather than from reproducing the artifact, so a before and after from your Fedora container and tmux is worth more than anything I can verify here. Both directions if you can manage it, since growing and shrinking take different paths through that handler.