Issue Station
Sign In
Tools hereToolbox

claude-code - 💡(How to fix) Fix [BUG] CJK (Korean) wide glyphs render as blank cells after scroll indicator overlay passes over them in fullscreen TUI [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
anthropics/claude-code#52290•Fetched 2026-04-24 06:11:04
View on GitHub
Comments
0
Participants
1
Timeline
4
Reactions
0
Author
yourkase-chaehyunyourkase-chaehyun
Participants
yourkase-chaehyunyourkase-chaehyun
Timeline (top)
labeled ×4

Error Message

Error Messages/Logs

Code Example

No errors or crash logs — this is a pure rendering / cell-invalidation
issue. Nothing is emitted to stderr or ~/.claude logs when it happens.
RAW_BUFFERClick to expand / collapse

Preflight Checklist

  • I have searched existing issues and this hasn't been reported yet
  • This is a single bug report (please file separate reports for different bugs)
  • I am using the latest version of Claude Code

What's Wrong?

In Claude Code's fullscreen TUI, individual CJK (Korean) wide-glyph characters render as blank/grey cells almost every time I scroll. The trigger appears to be the transient scroll-position indicator overlay sliding across previously-painted text — once the overlay moves away, the cells it crossed are not fully repainted and the underlying wide glyph disappears.

Only CJK/wide glyphs are affected; ASCII characters on the same rows render correctly. Drag-selecting over the blank cells with the mouse forces a repaint and makes the glyphs visible again, but scrolling once more returns them to the blank state.

Tested only on Ghostty so far — I haven't verified whether the sa issue reproduces on iTerm2 / Terminal.app / WezTerm, soit may be a Ghostty-specific rendering interaction rather than a Claude Code bug. Filing here in case the TUI's redraw/invalidation logic is the side that needs to account for it.

What Should Happen?

After the scroll-position indicator overlay is cleared, the cell region it covered should be fully repainted so the underlying CJK characters remain visible. No manual drag-select should be needed to restore them.

Error Messages/Logs

No errors or crash logs — this is a pure rendering / cell-invalidation
issue. Nothing is emitted to stderr or ~/.claude logs when it happens.

Steps to Reproduce

  1. Open Claude Code in Ghostty, large enough to enter fullscreen TUI mode.
  2. Generate a long Korean (or any CJK) response — enough text that the viewport needs to scroll.
  3. Use the app normally (scroll, interact). Within a short time, some CJK characters will appear as empty/grey cells.
  4. Drag-select across a blank cell with the mouse — the glyph reappears, confirming it's a repaint issue rather than lost data.
  5. Continue using the app → the same or nearby cells blank out again.

NOTE: I can't give a 100% deterministic repro recipe. My best guess is that scrolling (and the scroll-position indicator overlay sliding over text) is involved, but I have not verified this. The symptom is reproducible near 100% of the time during normal fullscreen TU the exact trigger is not confirmed.

<img width="638" height="388" alt="Image" src="https://github.com/user-attachments/assets/46909dc0-5a0f-473b-9b13-98612e96b612" />

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

2.1.118

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Environment:

  • OS: macOS (

  • Terminal: Ghostty 1.3.0 ← only tested here

  • Shell: zsh

  • Claude Code: v2.1.118

  • Node: v20.19.4

  • Locale: ko_KR.UTF-8

  • Font: <fills Lilex/ NotoSans KR fallback>

extent analysis

TL;DR

The issue can be addressed by adjusting the repaint logic in Claude Code's TUI to account for the scroll-position indicator overlay.

Guidance

  • Investigate the TUI's redraw/invalidation logic to ensure it properly handles the scroll-position indicator overlay.
  • Verify if the issue is specific to Ghostty or if it occurs on other terminals like iTerm2, Terminal.app, or WezTerm.
  • Check if the problem is related to the locale or font settings, specifically the use of ko_KR.UTF-8 and the Lilex/NotoSans KR font.
  • Consider adding a forced repaint of the cell region after the scroll-position indicator overlay is cleared.

Example

No code snippet is provided as the issue is related to the rendering logic and requires a deeper understanding of the Claude Code's TUI implementation.

Notes

The issue may be specific to the Ghostty terminal or the ko_KR.UTF-8 locale, and further testing is needed to determine the root cause.

Recommendation

Apply a workaround by adjusting the repaint logic in Claude Code's TUI to ensure proper handling of the scroll-position indicator overlay, as this is the most likely cause of the issue.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#api#network issue#logging issue#authentication issue#prompt issue

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING