## Bug description When `CLAUDE_CODE_NO_FLICKER=1` is enabled, copying Korean (CJK) text from Claude Code output in Windows Terminal produces garbled/mojibake text. ## Reproduction steps 1. Set `CLAUDE_CODE_NO_FLICKER=1` in environment or `~/.claude/settings.json` 2. Launch Claude Code in Windows Terminal (PowerShell) 3. Ask Claude something that produces Korean text output 4. Select and copy the Korean text 5. Paste — the text is garbled ## Expected behavior Korean text should be copied co

## Terminal-side workarounds attempted (all failed) The following terminal/shell encoding settings were configured before reproducing, and none resolved the issue: 1. **`chcp 65001`** — Set console code page to UTF-8. No effect. 2. **PowerShell profile UTF-8 settings:** ```powershell [Console]::OutputEncoding = [System.Text.Encoding]::UTF8 [Console]::InputEncoding = [System.Text.Encoding]::UTF8 $OutputEncoding = [System.Text.Encoding]::UTF8 chcp 65001 > $null ``` No effect

No-flicker mode breaks Korean (CJK) text copy on Windows Terminal

Status Fixed / completed

Maintainer reply None cached

Workaround ✓ Mentioned in thread ↓

Activity 4 comments · opened Apr 3, 2026 · closed Apr 7, 2026

Bug description

When CLAUDE_CODE_NO_FLICKER=1 is enabled, copying Korean (CJK) text from Claude Code output in Windows Terminal produces garbled/mojibake text.

Reproduction steps

Set CLAUDE_CODE_NO_FLICKER=1 in environment or ~/.claude/settings.json
Launch Claude Code in Windows Terminal (PowerShell)
Ask Claude something that produces Korean text output
Select and copy the Korean text
Paste — the text is garbled

Expected behavior

Korean text should be copied correctly to the clipboard.

Actual behavior

Copied text is garbled with encoding corruption. Example:

Original text (in Claude Code output):

shift 드래그에 대해 얘기하지말것. 터미널스웜 브라우저에선 안되니까. 깨지는건 아래처럼깨져서 나옴.

After copy-paste:

혻shift ?쒕옒洹몄뿉 ????섍린?섏?留먭쾬. ?곕??쏆뒪??釉뚮씪?곗??먯꽌 ?덈릺?덇퉴. 源⑥??붽굔

This is a classic CP949 (Korean legacy encoding) ↔ UTF-8 mismatch pattern, suggesting the alternate screen buffer content is being read with the wrong encoding during clipboard copy.

Environment

OS: Windows 11 Pro (10.0.26200)
Terminal: Windows Terminal (latest)
Shell: PowerShell
Code page: 65001 (UTF-8, set via chcp 65001 and PowerShell profile [Console]::OutputEncoding = UTF-8)
Claude Code version: latest
Setting: CLAUDE_CODE_NO_FLICKER=1

Notes

English and numeric text copies correctly — only CJK (Korean) characters are affected.
Disabling no-flicker mode (CLAUDE_CODE_NO_FLICKER=0) resolves the issue, but loses the flicker-free rendering benefit.
The issue appears to be related to how the alternate screen buffer interacts with Windows Terminal's text selection/clipboard for multi-byte characters.

View original on GitHub ↗

4 Comments

github-actions[bot] · 6 months ago

Found 2 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

somegee · 6 months ago

Terminal-side workarounds attempted (all failed)

The following terminal/shell encoding settings were configured before reproducing, and none resolved the issue:

chcp 65001 — Set console code page to UTF-8. No effect.
PowerShell profile UTF-8 settings:

``powershell [Console]::OutputEncoding = [System.Text.Encoding]::UTF8 [Console]::InputEncoding = [System.Text.Encoding]::UTF8 $OutputEncoding = [System.Text.Encoding]::UTF8 chcp 65001 > $null``
No effect — garbled text persists when copying from no-flicker mode output.

This suggests the encoding mismatch occurs at the alternate screen buffer ↔ clipboard layer, not at the shell encoding layer.

somegee · 6 months ago

Additional workarounds attempted (all failed)

Tested all Windows Terminal rendering engine options — none resolved the issue:

"rendering": { "graphicsAPI": "direct3d11" } — No effect.
"rendering": { "graphicsAPI": "software" } — No effect.
"rendering": { "graphicsAPI": "direct2d" } — No effect.

Combined with the earlier shell encoding fixes (#1–2), this confirms the issue is not fixable through terminal-side configuration. The problem lies in how no-flicker mode's alternate screen buffer content is encoded/exposed to the clipboard on Windows.