[BUG] TUI overprints new output on top of old lines in iTerm2 (still occurring on 2.1.278; continuation of auto-closed #68461)

Status Open
Reported on v2.1.280
Maintainer reply None cached
Activity 0 comments · opened Sep 22, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet (closest open issues are #84247, which is resize-specific, and #29937, which is tmux-specific; neither matches this report)
  • [x] This is a single bug report
  • [x] I am using the latest version of Claude Code (2.1.280 installed; the affected long-lived session was still running 2.1.278, see Environment)

What's Wrong?

In long-running interactive sessions in iTerm2, the TUI intermittently prints new lines on top of lines already on screen, leaving unreadable stacked text. Today it happened twice within two minutes in one session (2026-09-22, 10:48 and 10:49 MDT):

  1. Status/footer chrome drawn into the middle of a diff (screenshot captured). While a Python diff was displayed, the session title line ("<session name> | Opus · auto effort"), the "✔ Update installed · Restart to update" notice and the "● high · /effort" footer chrome were all rendered into the diff region several rows above where they belong, splicing character-for-character into a diff row (the row reads "Trai 98g Text Drop Fix ..." where diff line 98's text and the title line occupy the same cells).
  2. One sentence of assistant response text rendered twice, the second copy printed over the first at the same rows (observed a minute later in the same session; not captured before the screen moved on).

This is the same symptom class as #68461 (community bisect there pointed at the native-cursor rollout in 2.1.163, with oversized cursor-up sequences such as ESC[712A clamping at row 1 and desyncing the renderer's row model). That issue was auto-closed not_planned by the stale bot on 2026-09-04 without a shipped fix (see #87647 regarding auto-closures), so per the bot's own message I'm filing fresh: the symptom still occurs on current builds.

Local causes ruled out

  • No tmux. Plain iTerm2 tabs.
  • No window resize at the time of either occurrence (so not #84247).
  • No third-party TTY writers. I previously had local hooks that wrote escape sequences to session TTYs; all of them were disabled on 2026-09-20 behind a guard that logs and refuses every attempted write. The log shows 875 refused attempts and zero writes between the cutover and today's corruption. The corruption happened anyway.
  • CLAUDE_CODE_NATIVE_CURSOR is unset. No renderer-related env vars set. Default (main-screen) renderer, not /tui fullscreen.

What Should Happen?

New output should never overwrite previously rendered lines; the status line should only ever draw in its own row.

Steps to Reproduce

Not deterministic. Conditions where it recurs for me, a few times per week:

  1. macOS + iTerm2, 5-9 concurrent Claude Code tabs, sessions kept alive for many hours to days.
  2. Heavy interleaved output in the affected session (diffs, tool results, streaming text, status line updating).
  3. Corruption appears without a resize or focus change.

I have now enabled iTerm2 raw session logging (Raw data format), so I can supply a byte-level capture of the escape-sequence stream the next time it occurs. Happy to attach that here on the next occurrence.

Environment

  • Claude Code: 2.1.278 in the affected session (long-lived tab started 2026-09-21; 2.1.280 was installed on disk but the session had not restarted). History: same symptom seen across many builds since ~2.1.163.
  • Terminal: iTerm2 3.7.2
  • OS: macOS 26.6.2 (build 25G83), MacBook Pro M3 (arm64)
  • Shell: zsh
  • No tmux, no SSH, local sessions

View original on GitHub ↗