C:/Program Files/Git/copy command corrupts UTF-8 characters on Windows

[LicuVas]

Description

The /copy command in Claude Code corrupts UTF-8 characters when copying to Windows clipboard.

Environment

• OS: Windows 10/11
• Terminal: Windows Terminal / PowerShell
• Claude Code version: latest

Steps to Reproduce

1. Have Claude generate text with non-ASCII characters (e.g., Romanian diacritics: ă, ț, ș, î, â)
2. Include box-drawing characters (├, └, │, ─) in the output
3. Use /copy to copy the message
4. Paste into any text editor

Expected Behavior

Characters should be preserved exactly as displayed in the terminal.

Actual Behavior

Characters are corrupted (mojibake):

• ă → ─â
• ț → ╚Ť
• ș → ș
• ├── → ÔöťÔöÇÔöÇ
• └── → ÔööÔöÇÔöÇ

Example

Original (in terminal):

Excelentă observație
├── Item 1
└── Item 2

After /copy + paste:

Excelent─â observa╚Ťie
ÔöťÔöÇÔöÇ Item 1
ÔööÔöÇÔöÇ Item 2

Root Cause

Windows clipboard uses different encoding (CP-1252 or UTF-16) than UTF-8 used in the terminal. The /copy command likely doesn't explicitly encode as UTF-8 when writing to clipboard.

Suggested Fix

Use explicit UTF-8 encoding when copying to clipboard on Windows, possibly via pyperclip with proper encoding or Windows API with CF_UNICODETEXT format.

[shostako]

I'm experiencing the same issue on a Japanese Windows environment.

Environment:

• OS: Windows 11 (Japanese locale, system codepage CP932/Shift-JIS)
• Terminal: WezTerm
• Claude Code: v2.1.63

Reproduction:

1. Claude generates a response containing Japanese text and markdown tables
2. Run /copy
3. Paste into Notepad or Microsoft Word

Result:
Japanese text like これは v2.1.63 で追加された becomes garbled as 縺薙ｌ縺ｯ v2.1.63 縺ｧ霑ｽ蜉縺輔ｌ縺・. This is the classic pattern of UTF-8 bytes being interpreted as Shift-JIS (CP932).

Analysis:
The /copy command appears to write raw UTF-8 bytes to the Windows clipboard as CF_TEXT (ANSI), rather than using CF_UNICODETEXT (UTF-16). Since the system ANSI codepage on Japanese Windows is CP932, the UTF-8 bytes get misinterpreted.

This affects all non-ASCII characters — not just Romanian diacritics as originally reported, but also CJK characters, box-drawing characters, and any multibyte UTF-8 sequences.

Workaround:
Manual text selection in the terminal (e.g., WezTerm mouse select → auto-copy) preserves encoding correctly.

[shostako]

This appears to be fixed in v2.1.70. The release notes state:

Fixed clipboard corrupting non-ASCII text (CJK, emoji) on Windows/WSL by using PowerShell Set-Clipboard

I can confirm that /copy with Japanese text works correctly on v2.1.75 (Windows 11 + WezTerm + WSL). The issue can likely be closed.

[jhardin-accumula]

Still present in 2.1.89 (Claude Code)

Windows 11
Windows Terminal
not WSL