[BUG] Fullscreen mode: "Jump to bottom" overlay leaves color-block artifacts on wide characters (wcwidth-unaware clipping)

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?

In fullscreen / no flicker mode (CLAUDE_CODE_NO_FLICKER=1 or the equivalent /tui fullscreen mode), when scroll mode is active and the centered "Jump to bottom (ctrl+End) ↓" overlay is rendered on top of content lines, the overlay's left and right edges are not wcwidth-aware.

When the underlying line contains a double-width character that straddles the column where the overlay's edge lands, the overlay overwrites only one half of that character. The orphaned other half is left behind in the adjacent cell, and renders as a color block / garbled artifact. The artifact persists after the overlay moves away, because the cell is never re-cleared.

The bug is not language-specific:

• CJK Unified Ideographs (Chinese, Japanese kanji)
• Hiragana / Katakana
• Hangul Syllables
• Full-width Latin (FULLWIDTH LATIN block)
• Any other 2-cell character

Reproduces in Ghostty, Warp, and iTerm2 on macOS — i.e., across three independent terminal renderers — which rules out the terminal as a cause.

<img width="834" height="284" alt="Image" src="https://github.com/user-attachments/assets/2e5c2cea-ec5a-4d3b-b755-29541a27f4d0" />

What Should Happen?

The overlay's drawing path must be wcwidth-aware at both edges. Specifically, before writing the overlay text starting at column L:

1. If column L is the right half of a double-width character (i.e., a wide char occupies columns L-1 and L on the line being overlaid), the renderer must also clear column L-1 — otherwise the orphan left half remains.
2. Symmetrically at the right edge: if column R+1 is the left half of a wide character, the renderer must also clear column R+1.

Equivalently, the overlay's effective draw range should be expanded to the smallest column range whose extent contains only whole grapheme clusters of the underlying line.

Error Messages/Logs

Steps to Reproduce

1. Resize the terminal to a width where the centered overlay text lands on a wide-character mid-cell. Width 120 columns puts the overlay's left edge at column 47, which is the easiest to reproduce.
2. Start Claude Code in fullscreen / no-flicker mode:

``
CLAUDE_CODE_NO_FLICKER=1 claude
``

1. Have Claude output the following test content (5 lines + ruler):

```
1 2 3 4 5 6 7 8 9 10
1234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890

AS This is a regular ASCII English line for the control row test here
EN ＨｅｌｌｏＷｏｒｌｄＨｅｌｌｏＷｏｒｌｄＨｅｌｌｏＷｏｒｌｄＨｅｌｌｏＷｏｒｌｄ
ZH 中文双宽字符渲染色块测试中文双宽字符渲染色块测试中文双宽字符渲染
JP 日本語テスト日本語テスト日本語テスト日本語テスト日本語テスト日本語
KR 한국어테스트한국어테스트한국어테스트한국어테스트한국어테스트한국어
```

1. Output additional content so that scrolling up triggers the "Jump to bottom (ctrl+End) ↓" overlay.
2. Scroll up slowly so the overlay passes over the 5 test lines.

Expected: all 5 lines render cleanly.

Actual: at columns 46–47:

| Row | Script | Char at cols 46–47 | Artifact? |
| --- | ------------------- | ------------------- | ------------------------ |
| AS | ASCII (control) | h e | ❌ no — clean |
| EN | Full-width Latin | ｅ | ✅ color block at col 46 |
| ZH | Chinese | 块 | ✅ color block at col 46 |
| JP | Japanese (katakana) | テ | ✅ color block at col 46 |
| KR | Korean (Hangul) | 테 | ✅ color block at col 46 |

A complementary artifact also appears at the overlay's right edge (around column 74 at terminal width 120) on lines where a wide character straddles that boundary.

The AS / EN contrast is informative: identical "English-looking" content, but the half-width version is clean while the full-width version triggers the bug — proving this is purely a wcwidth issue, not anything language-specific.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.131

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

iTerm2

Additional Information

Cross-terminal reproduction: Ghostty, Warp, iTerm2 — all show the same artifact, confirming the bug is in Claude Code's TUI renderer, not in any terminal.

Width sensitivity: Because the "Jump to bottom" overlay is horizontally centered, its edge columns are a function of terminal width. Some widths happen to land the edges on "safe" positions (where the edge aligns with the start of a wide character, not its middle), in which case the artifact does not appear. Reducing terminal width to 120 cols reliably reproduces it.

Diagnostic confirmation: I tested with two control conditions:

1. A "uniform" block where every line is identical and double-width characters land at fixed positions: no artifact (likely because the renderer takes a scroll-shift fast path for unchanged lines).
2. A "sweep" block where each line shifts the wide-character alignment by 1 column: artifacts appear only on the lines where a wide char actually straddles the overlay's edge column, in a clean odd/even pattern.

This pinpoints the trigger as: wide char's left half at column N-1 and right half at column N, where N is the overlay's left edge column. Lines where a wide char starts cleanly at column N (without straddling) are unaffected.

Likely root cause: the overlay's draw call writes single-width content at the overlay's left edge column without checking whether the underlying line's cell at that column is the right half of a wide character. The terminal correctly executes the write, but the orphaned left half is never repaired.

Suggested fix: before drawing the overlay, scan the underlying line at the overlay's edge columns; if either edge column lands mid-character, expand the clear range by one column to cover the whole grapheme cluster.

Related issues (not duplicates):

• #45407 — "Jump to bottom ↓" included in text selection/copy in fullscreen mode (same UI element, different bug)
• #23534 — CJK full-width characters clipped at right terminal edge during text wrapping (same wcwidth class of bug, different location)