## Summary Starting in 2.1.163, the TUI miscalculates cursor position after rendering. Two linked symptoms on every response: 1. The cursor lands in the wrong row — visibly floating in empty space below the prompt. 2. Subsequent output is painted *on top of* already-rendered text, clobbering it (not just a stray cursor — real text overwrites real text). This makes the session progressively unreadable as responses stack. ## Regression - **2.1.162:** clean. Renders correctly, cursor tracks prop

Renderer paints cursor in wrong position and overprints existing text on every response (regression introduced in 2.1.163)

Status Fixed / completed

Reported on v2.1.163

Maintainer reply None cached

Workaround ✓ Mentioned in description ↑

Activity 4 comments · opened Jun 16, 2026 · closed Jul 5, 2026

Summary

Starting in 2.1.163, the TUI miscalculates cursor position after rendering. Two linked symptoms on every response:

The cursor lands in the wrong row — visibly floating in empty space below the prompt.
Subsequent output is painted on top of already-rendered text, clobbering it (not just a stray cursor — real text overwrites real text).

This makes the session progressively unreadable as responses stack.

Regression

2.1.162: clean. Renders correctly, cursor tracks properly. (last good)
2.1.163: broken, as above. (first bad)
Confirmed still broken through 2.1.179.

Reproduction

On 2.1.163+, send any prompt that produces a multi-line response.
Observe the cursor settle in the wrong row after the response renders.
Send another prompt — new output overprints the previous response's text.

Content-independent: reproduces with plain prose as well as markdown (tables / code blocks / emoji). It is not tied to wide characters or any specific markdown construct — every response drifts.

What I ruled out

Plugins / hooks / statusline / custom skills — reproduces under --safe-mode.
Terminal multiplexer — reproduces both inside tmux 3.5a and in a bare terminal (no tmux).
Markdown / emoji width — reproduces on plain-text responses too.

Environment

OS: macOS 25.5.0 (Darwin 25.5.0), arm64 (Apple Silicon)
Claude Code: first bad 2.1.163, last good 2.1.162, native install
Terminal: tmux 3.5a (TERM=tmux-256color) and bare terminal both affected
COLORTERM=truecolor

Workaround

Downgrade to 2.1.162: repoint the native shim (~/.local/bin/claude → versions/2.1.162) with autoupdate disabled.

View original on GitHub ↗

4 Comments

TelpeNight · 3 months ago

The same bug w/o tmux. Claude code became almost unusable.

RRikor · 3 months ago

This looks like the same regression I've been tracking in #67887 (TUI garbling / lines breaking up over a session) — cross-linking so they can be deduped.

Your bisect is tighter than mine, and I think it supersedes my conclusion there. My data, for what it's worth as an independent confirmation on a different platform:

2.1.168: broken (lines break up / output garbles after a while)
2.1.165: noticeably better in a ~30-min session — but that was subjective, and I never tested down to 2.1.162/2.1.163, so your 162 good → 163 first bad boundary is very plausibly the real one. 2.1.165 may just be less severe, not clean.

Two things from your report that update my thinking:

In #67887 I'd suspected the 2.1.166 "enabling synchronized output" change. Your 162→163 boundary predates that, so synchronized output is likely not the root cause (at most a second contributing factor).
You reproduce in a bare terminal and under --safe-mode, which rules out the tmux-interaction theory I'd leaned on.

Extra platform coverage — this is not macOS-only:

OS: Manjaro Linux, Kernel 6.12.91 (x86_64)
DE/WM: KDE Plasma 6.6.5 / KWin (X11)
Terminal: Alacritty 0.17.0
Multiplexer: tmux 3.6b, TERM=tmux-256color
Shell: zsh 5.9

So: Linux+tmux and macOS (tmux + bare) both affected, regression in the low 2.1.16x range. Happy to test a fix or capture a raw escape-sequence dump.

and-0-1 · 3 months ago

Unsure the exact version it got fixed, but no longer have this issue after i upgraded to 2.1.197

github-actions[bot] · 1 month ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.