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

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.