New renderer (CLAUDE_CODE_NO_FLICKER=1): Japanese text clipboard copy garbled on Windows (UTF-8 → CP932 mojibake via OSC 52)

[NakayoshiUsagi]

Bug Description

When the new fullscreen renderer is enabled (CLAUDE_CODE_NO_FLICKER=1), copying Japanese (CJK) text from the terminal results in mojibake in the clipboard. UTF-8 byte sequences are interpreted as CP932 (Shift-JIS), the default Windows ANSI code page for Japanese locale.

Examples:

• これで → 縺薙ｌ縺ｧ
• — (em dash, U+2014) → ﾂｷ

Environment

• OS: Windows 11 Home (10.0.26200)
• Terminal: Windows Terminal
• Shell: PowerShell 5.1 / Git Bash
• System code page: 932 (Shift-JIS)
• Claude Code: latest channel

Reproduction Steps

1. Launch Claude Code with CLAUDE_CODE_NO_FLICKER=1 claude
2. Generate any output containing Japanese text
3. Select text by mouse drag → status bar shows "sent N chars via OSC 52"
4. Paste into Notepad or any editor → garbled text

Diagnosis

Confirmed through systematic testing:

Test	Result	Conclusion
Copy with new renderer (drag / Ctrl+C)	Garbled (mojibake)	OSC 52 path is broken
Copy with Shift+drag (bypasses mouse capture)	Normal	Native terminal selection works
Manual OSC 52 send from Git Bash (printf '\e]52;c;...\a')	Normal	Windows Terminal OSC 52 implementation is correct
chcp 65001 before launching Claude Code	Still garbled	Console code page does not affect OSC 52 path

Conclusion: The bug is in how the new renderer constructs or sends the OSC 52 clipboard payload. Windows Terminal correctly handles OSC 52 with UTF-8 base64 payloads (verified independently). The issue likely occurs when the text passes through Node.js stdout → ConPTY, where byte sequences may be converted from UTF-8 to CP932 before reaching Windows Terminal's VT parser.

Workaround

• Shift+drag to select text (bypasses application mouse capture, uses terminal native selection)

Expected Behavior

Japanese text should be correctly copied to clipboard via OSC 52, regardless of system ANSI code page.

[github-actions]

Found 1 possible duplicate issue:

1. [Bug] NO_FLICKER mode garbles Japanese text output on Windows #42406

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

[ahnbu]

I’m seeing a very similar symptom on Windows.

In Claude Code TUI, using copy (Ctrl+C in my setup) shows this message above the status line:

sent N chars via OSC 52 · check terminal clipboard settings if paste fails

A few notes from my environment:

• This did not used to happen before.
• CLAUDE_CODE_NO_FLICKER=1 was enabled.
• Disabling CLAUDE_CODE_NO_FLICKER made the problem disappear.
• In the same Windows environment, Codex TUI does not show this behavior.

So at least in my case, this also looks related to the new renderer / Windows OSC 52 clipboard path, even when the main symptom is the visible status message itself.

[sahksas]

This issue is still occurring in v2.1.92.
I understand this feature is in preview, so turning it off is a fine workaround for now (though it's a shame to lose access to the latest features). However, I'm concerned that once this becomes the default, it will significantly degrade the UX for users of Japanese, Korean, Chinese, and potentially other non-ASCII languages.
Until this issue is resolved, I strongly request that you continue to allow users to disable CLAUDE_CODE_NO_FLICKER.

[ashwin-ant]

This was fixed in v2.1.97 — Clipboard copy on Windows now uses PowerShell Set-Clipboard with UTF-8, fixing garbled (mojibake) output for Japanese and other non-ASCII text. If you're still seeing this in the latest version, please comment with your version and repro and we'll reopen.

[sahksas]

@ashwin-ant
Even in v2.1.114, the same issue persists when running Claude Code on WSL2.

The fix introduced in v2.1.97 (supporting UTF-8 via PowerShell's Set-Clipboard) only functions when Claude Code detects that it is running on Windows. In a WSL2 environment, Claude Code operates as a Linux process, so it bypasses the OS detection, causing it to continue using the OSC 52 path that was identified as problematic in the original report.

Environment

• Claude Code: v2.1.114
• Host OS: Windows 11 (System code page 932 / Shift-JIS)
• Runtime: WSL2 (Ubuntu)
• Verified Terminals (reproducible in both): Windows Terminal, VS Code Integrated Terminal
• With CLAUDE_CODE_NO_FLICKER=1 set

Reproduction Steps

1. Launch CLAUDE_CODE_NO_FLICKER=1 claude in WSL2.
2. Have Claude output Japanese text (e.g., "テキスト").
3. Select the text by mouse dragging; "sent N chars via OSC 52" appears in the status.
4. Paste into Notepad; the text is garbled (e.g., "縺薙ｌ縺ｧ").

I have confirmed that the issue does not occur if I hold the Shift key while dragging to bypass mouse capture and use the terminal's standard selection feature.

When the host is Windows, could you please modify the output path to the WSL clipboard to also use powershell.exe Set-Clipboard (or avoid the conversion from UTF-8 to CP932 in the OSC 52 path)?