CJK text corrupted (mojibake) when copying terminal output — no-flicker/fullscreen renderer is the cause; tui: "default" fixes it [macOS + OrbStack]

Status Open

Reported on v2.1.168

Maintainer reply None cached

Activity 7 comments · opened Jun 8, 2026

Summary

When the no-flicker / fullscreen renderer is active ("tui": "fullscreen" in settings, equivalent to CLAUDE_CODE_NO_FLICKER=1, which is the default), copying CJK (Chinese) text out of the terminal produces mojibake on the clipboard. The text renders correctly on screen, but the copied bytes are corrupted, so it pastes garbled into any destination (another app, a web form, the Claude Code prompt itself).

Switching to the classic renderer with "tui": "default" completely fixes it — a clean, deterministic toggle.

This is the copy-out / output direction, on macOS, and is distinct from the previously reported Windows paste-in issues (#65806, #3961).

Environment

Claude Code: 2.1.168
Node: v22.22.2
Terminal: VS Code integrated terminal v1.123.0 (TERM_PROGRAM=vscode, TERM=xterm-256color)
OS: macOS 15.7.7 Sequoia (build 24G720) host, with Claude Code running inside an OrbStack Linux VM (Linux 7.0.5-orbstack x86_64)
Locale: C.UTF-8 (full UTF-8; display/fonts correct)
Trigger setting: "tui": "fullscreen" (≡ CLAUDE_CODE_NO_FLICKER=1) — the default
Fix setting: "tui": "default"

Steps to reproduce

Ensure "tui": "fullscreen" (default) in ~/.claude/settings.json.
Start claude in the VS Code integrated terminal.
Have Claude print some Chinese text, e.g. 陳嗣森你好世界. It renders correctly.
Select that Chinese text in the terminal and copy it (Cmd+C). Holding Shift to force native xterm.js selection does not help.
Paste into any destination — a text field, Gmail, or back into the Claude Code prompt.

Expected behavior

The pasted text matches what was on screen: 陳嗣森你好世界.

Actual behavior

The pasted text is mojibake — UTF-8 bytes interpreted as Latin-1/Windows-1252 (e.g. 中文 → ä¸æ–‡), and in some cases bytes are dropped, yielding invalid UTF-8. The exact garble varies by content.

Root cause (deterministic toggle)

Setting "tui": "default" in ~/.claude/settings.json and restarting Claude Code fixes the corruption — copying terminal output then yields correct CJK in all destinations. Setting it back to "fullscreen" reintroduces the corruption. So the defect is in the no-flicker / fullscreen (alt-screen) renderer's handling of wide (double-width) characters on the copy/selection path.

What is NOT the cause (isolation evidence)

Tested by holding the paste-target constant and varying the source:

| Source of copy | Result |
|---|---|
| Native macOS app (web page) → paste anywhere | ✅ clean |
| VS Code editor tab → paste anywhere | ✅ clean |
| Paste into the Claude Code prompt (from a clean source) | ✅ clean |
| Claude Code terminal output → paste anywhere (tui: fullscreen) | ❌ garbled |
| Claude Code terminal output → paste anywhere (tui: default) | ✅ clean |

So the macOS clipboard, the VS Code editor's clipboard path, OrbStack's byte delivery (the glyphs render correctly, proving correct UTF-8 reaches the terminal), and the paste/input path are all fine. The only variable that breaks it is the Claude Code fullscreen renderer.

Workaround

Set "tui": "default" in ~/.claude/settings.json and restart. Trade-off: the classic main-screen renderer flickers more on redraws and loses the alt-screen virtualized scrollback.

#65806 — Korean (CJK) paste-in mojibake on Windows via the no-flicker renderer (closed not-planned). Same renderer, opposite direction, different platform.
#3961 — earlier related report, closed stale.

This report adds: macOS, the copy-out direction, and a deterministic tui toggle that turns the bug on and off.

View original on GitHub ↗

6 Comments

github-actions[bot] · 2 months ago

Found 3 possible duplicate issues:

This issue will be automatically closed as a duplicate in 3 days.

If your issue is a duplicate, please close it and 👍 the existing issue instead
To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

aslom · 2 months ago

Possibly the same renderer subsystem, though my symptom is different from the CJK
mojibake — flagging in case it helps localize the cause.

On macOS + plain iTerm2 with the fullscreen / no-flicker renderer (the default),
copy-on-select reports a successful OSC 52 copy but nothing reaches the macOS
pasteboard at all (not corrupted — simply absent). Setting "tui": "default"
in ~/.claude/settings.json and restarting returns me to native iTerm2 selection
and the problem disappears, matching your "default fixes it / fullscreen
reintroduces it" finding.

So both the corruption you're seeing and the dropped-write I'm seeing sit on the
fullscreen renderer's copy/selection path — your case mangles the bytes, mine
loses the write entirely (in my setup the OSC 52 sequence depends on iTerm2's
"Applications in terminal may access clipboard" permission, which is off by
default). Same code path, two different failure modes. Tracking the no-clipboard-
write case separately in #66192.

Claude Code: 2.1.168 · macOS · iTerm2 · "tui": "fullscreen" (default).

heishen6 · 2 months ago

weilr · 2 months ago

Is there any other way besides setting "tui": "default"?

sjals93 · 2 months ago

Confirming this is not macOS/OrbStack-specific — same bug reproduces on Linux + VS Code integrated terminal.

Environment

Claude Code: 2.1.177
OS: Ubuntu 22.04 (Linux 5.15)
Terminal: VS Code integrated terminal 1.124.2 (TERM_PROGRAM=vscode, TERM=xterm-256color)
Locale: ko_KR.UTF-8 (locale is correct — not an encoding-setup issue)

Repro

Let Claude Code render Korean (CJK / wide) text to the terminal.
Select & copy that rendered output.
Paste into any other app (or back into the same terminal) → mojibake / corrupted bytes, even though it looked correct on screen.

Notes

Only the copy-out path is affected. Pasting CJK text into the prompt works fine on Linux.
Codex CLI in the exact same VS Code terminal does not have this problem, which points squarely at Claude Code's renderer rather than the terminal.
Started appearing ~a week ago, consistent with the no-flicker/fullscreen renderer being the default.

Workaround confirmed working: setting "tui": "default" in ~/.claude/settings.json (then restarting the session) eliminates the corruption.

AmaralVini · 1 month ago

Same bug on Windows + accented Latin characters (this issue is macOS/CJK, but it is the
same fullscreen renderer copy path).

Environment

Claude Code 2.1.197
Windows 11 (10.0.26200.8655)
VS Code integrated terminal 1.124.0, shell cmd.exe + Clink
tui: "fullscreen"

Repro: mouse-select rendered output containing Portuguese text, Ctrl+C, paste.

Result: UTF-8 decoded as Latin-1/CP1252 in the clipboard; the on-screen display is correct.

| Displayed | Copied |
|-----------|--------|
| é | Ã© |
| ã | Ã£ |
| sessão | sessÃ£o |
| índice | Ãndice |
| não | nÃ£o |

What I ruled out

Copying the same accented text from a native Windows cmd.exe window works fine.
Copying non-Claude-Code output (e.g. echo) from the same VS Code terminal works fine.
Display is always correct, so it is not a console code page issue.
tui: "default" (or /tui default) fully fixes it, isolating the cause to the

fullscreen/no-flicker renderer.

Note: Shift+drag (native selection) does not help in fullscreen; the constant redraw
clears the selection before Ctrl+C can act.

Likely the Windows Set-Clipboard copy path encodes as Latin-1 instead of UTF-8. The Windows
CJK variant (#42417) was reportedly addressed in v2.1.97 via Set-Clipboard, but it did not
generalize to accented Latin characters.

Showing cached comments. Read the full discussion on GitHub ↗