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

Found 1 possible duplicate issue:

1. https://github.com/anthropics/claude-code/issues/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

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.

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.

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.

@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)?

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

Workaround for VSCode panel users (claudeCode.preferredLocation: "panel")

For those using Claude Code inside the VSCode panel, setting CLAUDE_CODE_NO_FLICKER=0 in the shell session is not sufficient because the VSCode extension spawns its own environment.

Add the following to your Claude config file (e.g. ~/.claude/settings.json ):

{
  "env": {
    "CLAUDE_CODE_NO_FLICKER": "0"
  }
}

This ensures the variable is passed to Claude Code's internal process regardless of how it is launched.

Tested on: Windows 11, VSCode panel, Claude Code 2.1.167, Japanese locale (CP932).

Environment: Windows 11, VS Code integrated terminal

I'm experiencing the same issue. Copying any CJK (Chinese/Japanese) text from Claude Code and pasting anywhere results in mojibake (UTF-8 bytes misinterpreted as CP932/Shift-JIS).

I've tried the following without success:

1. Setting system locale to UTF-8 (Beta Unicode option in intl.cpl)
2. Running chcp 65001 before launching

The Shift+drag workaround does bypass the issue, but it's a significant UX regression for anyone working with CJK text regularly. Copy/paste is a core workflow.

Given that this affects all Windows users with CJK locales, I'd like to request this be reconsidered for a fix. The root cause (OSC 52 payload encoding in the new renderer) seems well-understood from the earlier analysis in this thread.

This is a VS Code bug, not Claude Code. VS Code 1.123 and 1.124 ship @xterm/addon-clipboard@0.3.0-beta.220, whose OSC 52 handler decodes the base64 payload with bare atob() and writes the resulting Latin-1 binary string to the clipboard without a UTF-8 decode so every multi-byte character becomes â…. Claude Code is sending correctly-encoded UTF-8.

Tracked and fixed upstream: xtermjs/xterm.js#6000 → xtermjs/xterm.js#6002, picked up by VS Code in microsoft/vscode#320646.

Fix: update VS Code to 1.125 or later (or stay on ≤1.122).
Workaround on 1.123/1.124: mouse-select + Cmd/Ctrl+C in the terminal — that copies the rendered cells and bypasses OSC 52.