[Bug] Unicode characters render as mojibake on Windows terminals

Seeing the same class of issue on v2.1.81 (Windows 11 Home 10.0.26220, VS Code integrated terminal, Git Bash).

Additional observations that may help narrow the cause:

1. Intermittent onset — not every session is affected. Some sessions render cleanly, others garble. Anecdotally, it seems to correlate with longer sessions (rough estimate: 200k+ tokens of 1M context), but I can't confirm causation — it may just be that longer sessions have more opportunities to trigger whatever encoding state change causes this.
2. Session-persistent — once the garbling starts in a session, it persists. Closing the terminal and resuming the session (/resume) in a new terminal reproduces the garbled output. The corrupted state appears to be in the session history, not the terminal.
3. Clears on VS Code restart — restarting VS Code entirely and resuming the same session can clear it (though not guaranteed).
4. Affects both Edit tool diffs and regular text responses — not limited to UI chrome/decorative elements. Response prose and diff removed-lines both render as garbled characters.
5. Selection reveals correct text — highlighting the garbled text with cursor selection causes the correct text to appear. This suggests the correct bytes are in the terminal buffer but the initial render draws them incorrectly — a paint/rendering state issue rather than a true encoding mismatch. Possibly a leaked or unclosed ANSI escape sequence corrupting subsequent render passes.

Environment:

• Claude Code: 2.1.81
• OS: Windows 11 Home 10.0.26220
• Shell: bash (Git Bash) in VS Code integrated terminal
• Not using the Claude Code VS Code extension — CLI directly in terminal

Concrete Reproduction: Box-Drawing Table Corruption on Paste (v2.1.89, Windows)

Still occurring on v2.1.89. Here's exactly what happens:

Step 1: Claude Code generates a table with box-drawing characters in Window A:

┌──────┬────────────────────────┬────────┬──────────────┐
│ Rank │        Feature         │   d    │     Type     │
├──────┼────────────────────────┼────────┼──────────────┤
│ 1    │ pnl_pct_of_peak        │ +1.276 │ Position     │
└──────┴────────────────────────┴────────┴──────────────┘

Step 2: Copy that output and paste into Window B's prompt. Result:

ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ
Γöé Rank Γöé        Feature         Γöé   d    Γöé     Type     Γöé
Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ
Γöé 1    Γöé pnl_pct_of_peak        Γöé +1.276 Γöé Position     Γöé
ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ

Every box-drawing character (U+2500-U+257F) and every em dash (U+2014) is corrupted. The UTF-8 bytes are being interpreted as Windows-1252/CP1252.

Also corrupts:

• — (em dash) → ΓÇö
• – (en dash) → ΓÇô
• ≥ (greater-equal) → ≥

Impact for multi-agent workflows: When Agent A produces a formatted table and the user pastes it into Agent B's window for review, the table is unreadable. This breaks cross-agent communication in any workflow involving structured output.

Environment: v2.1.89, Windows 11, PowerShell / Windows Terminal, clipboard copy-paste between two Claude Code windows.

Note: v2.1.89 fixed CRLF doubling and Devanagari truncation on Windows, but this clipboard encoding issue remains.

Still broken on v2.1.90 (April 2, 2026). No encoding/Unicode fixes in the v2.1.90 changelog. Box-drawing characters (─│├┤┌┐└┘), em dashes (—), en dashes (–), and ≥ symbols still corrupted to CP1252 mojibake (ΓöÇ, Γöé, ΓÇö, ΓëÑ) when pasting between Claude Code windows on Windows.

Clarification on reproduction path: the table renders correctly in the originating Claude Code window. The corruption happens specifically on the clipboard copy-paste path BETWEEN windows.

Exact flow:

1. Agent A (task agent) generates table with box-drawing characters — displays correctly
2. User copies output from Agent A's terminal window
3. User pastes into Agent B's (PM agent) terminal window
4. Characters are corrupted — UTF-8 bytes interpreted as CP1252

This means the rendering pipeline is fine. The bug is in how Claude Code's terminal output hits the clipboard — either the terminal's copy operation is encoding as CP1252 instead of UTF-8, or Claude Code's alt-screen/Ink rendering is writing bytes that the terminal clipboard handler misinterprets.

This is the primary workflow for multi-agent orchestration: copy results from one agent, paste into another for review. It's broken end-to-end on Windows.

Still broken on v2.1.91 (April 2, 2026). Third consecutive release with no fix.

v2.1.89 — broken
v2.1.90 — broken
v2.1.91 — broken

Nothing in any of these changelogs addresses clipboard encoding on Windows. The UTF-8 to CP1252 mojibake still corrupts every box-drawing character, em dash, en dash, and ≥ symbol when pasting between Claude Code windows.

This is the primary workflow for multi-agent orchestration: Agent A produces structured output, user copies it, pastes into Agent B for review. It's been broken for at least 3 releases and there's been zero acknowledgment from Anthropic on this thread.

Can we at least get a response on whether this is being tracked internally?

v2.1.92 — still broken. That's five consecutive releases with no fix and zero responses from Anthropic on this thread. UTF-8 to CP1252 mojibake on paste between windows persists. Box-drawing characters, em dashes, en dashes all corrupted. This is not a fringe use case — it's the core multi-agent copy/paste workflow broken on Windows.

Five Releases. Zero Fixes. Zero Responses.

v2.1.89 — broken
v2.1.90 — broken
v2.1.91 — broken
v2.1.92 — broken

Not a single entry in any of these changelogs addresses clipboard encoding on Windows. Not a single response from an Anthropic engineer on this thread.

This is not an edge case. This is the core multi-agent copy/paste workflow: Agent A generates output, user copies it, pastes into Agent B. Every box-drawing character, em dash, and mathematical symbol is destroyed in transit. Tables become unreadable. Results can't be shared between windows.

Claude Code is built around multi-agent workflows. The copy/paste path between those agents is broken on Windows. Five releases. No acknowledgment. No ETA. Nothing.

What does it take to get a response on a Windows bug?

Cross-referencing the full Unicode bug cluster on Windows

For anyone triaging: this is not an isolated report. There are at least three open issues describing the same UTF-8 → CP1252 clipboard corruption on Windows, none of which have received a response:

• #34247 (this issue) — mojibake on Windows terminals, general
• #41235 — /copy command corrupts UTF-8 on Windows, regression filed March 31
• #29699 — Edit tool Unicode mojibake in .md files on Windows

All three: open, unacknowledged, unfixed across v2.1.89 → v2.1.90 → v2.1.91 → v2.1.92.

The specific workflow that is broken: Claude Code Agent A generates a table with box-drawing characters. User copies output. Pastes into Agent B. Every character above ASCII 127 is corrupted. This is not a niche use case — it is the default way users share results between agent windows.

The fact that three separate issues describe the same problem with no cross-referencing or triage suggests this hasn't been looked at. Tagging all three here so they can be consolidated and actually addressed.

Still broken on v2.1.94 (upgraded yesterday, Apr 7). This is now confirmed across 6 consecutive releases: v2.1.89, v2.1.90, v2.1.91, v2.1.92, v2.1.93, v2.1.94.

v2.1.94 shipped 'Fixed CJK and other multibyte text being corrupted with U+FFFD in stream-json input/output when chunk boundaries split a UTF-8 sequence' — that fix is for a different code path (stream-json chunk boundaries). The clipboard UTF-8 → CP1252 encoding bug on Windows is untouched.

What I'm seeing on v2.1.94: CLI output containing status icons renders as ✻ and Γ¥» in the terminal — not just clipboard paste, but the raw output stream is now also corrupted. That is regression on top of regression.

Reproduction is trivial: run any agent on Windows that generates output with non-ASCII characters (checkmarks, arrows, box-drawing, em dashes). Every character above ASCII 127 is mangled. This affects every Windows user running multi-agent workflows.

6 releases. Zero acknowledgment. Zero ETA. The label says has repro — someone confirmed it reproduces. What is the triage status? Is this assigned? Is there a milestone? At minimum, a 'we see this, it's in the queue' response would be better than silence.

CONFIRMED FIXED on v2.1.97.

The v2.1.97 changelog entry 'Fixed Korean/Japanese/Unicode text becoming garbled when copied in no-flicker mode on Windows' addressed this. Verified working on Windows 11 Pro x64 with CLAUDE_CODE_NO_FLICKER=1 — box-drawing characters, em dashes, and status icons are no longer corrupted on copy/paste between agent windows.

After 6 consecutive broken releases (v2.1.89 through v2.1.92), this is finally resolved. The fix was specifically scoped to NO_FLICKER mode on Windows, which is the configuration where the corruption was most severe.

For me, on Windows, installing via npm (npm install -g @anthropic-ai/claude-code) seems to have resolved the mojibake issue, while the bundled installer reproduces it.

System is:

Windows 11 25H2
Node v24.4.1.

The bundled Node runtime appears to handle multibyte UTF-8 stdout differently than the system Node when writing through ConPTY.

---

Claude CLI Mojibake on Windows — Debugging Log

What actually fixed it

npm install -g @anthropic-ai/claude-code instead of the bundled .exe installer. The bundled Claude installer ships its own Node.js runtime, which has broken multibyte UTF-8 stdout handling through ConPTY. Using the system Node (v24.4.1) fixed it.

Things that did NOT fix it

Terminal emulator changes

• Installed Tabby (replaced Windows Terminal)
• Unchecked "Use ConPTY" in Tabby (switched to winpty backend)
• Switched Tabby default profile from Git Bash to PowerShell 7

Shell changes

• Tested in Git Bash (MSYS2 bash)
• Tested in Windows PowerShell 5.1
• Tested in PowerShell 7 (pwsh.exe)
• Tested in Windows Terminal with Git Bash
• Used winpty claude wrapper inside Git Bash

Font changes

• Installed JetBrainsMono Nerd Font (replaced Cascadia Code)

Code page / encoding

• Added chcp.com 65001 to .bashrc
• Added chcp 65001 to PowerShell profile
• Set [Console]::OutputEncoding = UTF8 in PowerShell profile
• Set [Console]::InputEncoding = UTF8 in PowerShell profile
• Set $OutputEncoding = UTF8 in PowerShell profile
• setx LANG en_US.UTF-8 as Windows user env var
• export LC_ALL=en_US.UTF-8 in .bashrc
• export LESSCHARSET=utf-8 in .bashrc
• export PYTHONIOENCODING=utf-8 in .bashrc
• Disabled "Beta: Use Unicode UTF-8 for worldwide language support" + rebooted

MSYS2 runtime

• setx MSYS enable_pcon (system env var)
• Set MSYS=enable_pcon in Tabby Git Bash profile
• Swapped msys-2.0.dll with coworker's 3.5.4 version (from Git 2.47.0)

Claude Code env vars / settings

• Set CLAUDE_CODE_NO_FLICKER=1
• Set NO_COLOR=1
• Removed TERM=dumb from Claude's env settings
• Removed PostToolUse Bash hook (printf '\033[m\033[?25h')

Git config

• Changed core.pager from less -r to less -rFX (prevent alt screen buffer)

Windows

• Upgraded Windows from 11 22H2 (22621.4317) to 11 25H2 (26200.8117)
• Verified system code page registry values (ACP/OEMCP/MACCP)
• Verified Windows system locale and user locale (en-US)

Still reproducing on v2.1.110 (2026-04-16)

Original reporter here. This bug is still present on the latest version. Updating my environment details:

Environment

• Claude Code: 2.1.110 (standalone binary, ~/.local/bin/claude)
• OS: Windows 11 Home Build 26200
• Node.js: v22.21.0
• npm: 10.9.4
• Shell: Git Bash (GNU bash 5.2.37, MINGW64_NT-10.0-26200)
• Terminal: Windows Terminal 1.23.20211.0
• TERM: xterm-256color
• LANG / LC_ALL: en_US.UTF-8
• Active Code Page: 65001 (UTF-8)
• Console Output/Input Encoding: UTF-8 (CP65001)
• System ACP / OEMCP: 65001 / 65001 (Windows UTF-8 beta enabled)
• System Locale: ja-JP
• Culture: ja-JP
• WT_SESSION: Set (running inside Windows Terminal)
• CLAUDE_CODE_NO_FLICKER=1

Observations

• All UTF-8 settings are correctly configured at every layer (Windows beta UTF-8, code page 65001, console encoding, LANG/LC_ALL).
• The shell itself renders Unicode perfectly fine — running printf '━━━ … → ─── █ ·' in the same terminal displays correctly.
• Only Claude Code's TUI decoration characters (progress bars, spinners, box-drawing, ellipsis, bullets, arrows) render as mojibake (e.g. … → …, · → ·).
• Actual text content (code, English/Japanese responses) renders correctly — the issue is isolated to the TUI rendering layer.
• The problem is 100% consistent, not intermittent.
• WSL workaround still works — running Claude Code inside WSL has no rendering issues.

Additional note

NODE_OPTIONS=--encoding=utf-8 is set in my environment (attempted workaround), but this is not a valid Node.js flag and has no effect on the issue. The bug occurs with or without it.

This has persisted across multiple Claude Code versions (reported initially on 2.1.76, now confirmed on 2.1.110). The root cause appears to be in how Claude Code's TUI pipeline writes Unicode bytes to the Windows console — likely a missing explicit UTF-8 encoding declaration in the Ink/React-based renderer's stdout stream, causing Windows to fall back to a legacy codepage interpretation for the raw bytes.

Still reproducing on v2.1.132 (standalone binary, ~/.local/bin/claude.exe).

Environment

• Claude Code: 2.1.132
• OS: Windows 11 Pro Build 26200 (25H2)
• Node.js: v24.11.1
• Shell: PowerShell 7.6.0
• Active Code Page: 65001 (UTF-8)
• Console OutputEncoding: UTF-8
• System ACP / OEMCP: 1252 / 437 (Windows UTF-8 beta is NOT enabled)
• Install method: Standalone binary (claude.exe)

Observations

• TUI decoration characters (progress bars, spinners, box-drawing, em dashes, ellipses) render as mojibake — same UTF-8 → CP1252 pattern reported throughout this thread.
• Actual text content (code, responses) renders correctly.
• The issue is 100% consistent, not intermittent.
• Notably, my system ACP is 1252 (not 65001) — the Windows UTF-8 beta is not enabled. The console code page is set to 65001 via chcp, but the underlying system code page remains legacy Western European. This may be a contributing factor: Claude Code's TUI renderer may be relying on the system ACP rather than the console code page when writing multibyte characters.

Additional data point

One commenter above reported that installing via npm install -g @anthropic-ai/claude-code (using system Node) fixed the issue while the standalone binary reproduces it. I'm using the standalone binary — this is consistent with the theory that the bundled Node runtime in the standalone installer handles multibyte UTF-8 stdout differently through ConPTY.

I'm using Claude Code through VSCode and am still having this issue. I spent 3 hours last night trying to find 'em all and still missed some.

<img width="266" height="136" alt="Image" src="https://github.com/user-attachments/assets/38d36915-2287-4141-9c0d-f7fccebbca08" />

Node.js version is v24.15.0.

This is the 3rd PR I've gotten with a bunch of character changes:
https://github.com/Sawtaytoes/mux-magic/pull/109/changes

<img width="1170" height="781" alt="Image" src="https://github.com/user-attachments/assets/3d2922a6-4db5-48ae-9d22-dc09344a0e93" />

I'm burning tokens trying to fix this. If I could at least run a program to fix these characters, that'd at least mitigate the issue.

I don't even understand why it's happening. Claude is horrible at fixing it. I even killed a whole branch and had Claude start over, but it _still_ did the same thing. There must be something in some of my prompts causing this issue because it's inconsistent.

.editorconfig is utf-8 as are other tools. I have Biome installed. Is it possible running biome format or eslint --fix is the cause?

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.