Pasted Unicode text mojibake — UTF-8 decoded as MacRoman/CP-1252 in TUI

Summary

Pasting text containing non-ASCII characters (arrows, curly quotes, em-dashes, etc.) into the Claude Code prompt on macOS renders as mojibake. The pasted UTF-8 bytes are decoded byte-by-byte as a legacy 8-bit encoding (Mac Roman fits the pattern), corrupting the prompt. Typed Unicode input is unaffected — only paste is corrupted, which points to the bracketed-paste decode path rather than general stdin handling.

Reproduction

1. Copy text containing any non-ASCII char, e.g. →, ' (U+2019 right single quote), — (em-dash).
2. Paste into the Claude Code prompt.
3. Observe mojibake instead of the original characters.

Expected vs Actual

| Char | UTF-8 bytes | Expected | Actual (pasted) |
|---|---|---|---|
| → (U+2192) | E2 86 92 | → | ‚Üí (renders ,Üí) |
| ' (U+2019) | E2 80 99 | ' | ’ (renders ,Äô) |
| — (U+2014) | E2 80 94 | — | — (renders ,Äî) |

The ‚Xy signature is the unambiguous fingerprint of UTF-8 bytes decoded as Mac Roman (0xE2 → ‚, 0x80 → Ä, 0x86 → Ü, ...). The corrupted text is what lands in the prompt, so this is input-path corruption, not just a display artifact.

Environment

• OS: macOS 26.5.2 (build 25F84)
• Claude Code version: 2.1.211
• Terminal: Agent Grid — an Electron app driving Claude Code through a Node PTY (node-pty)
• Locale: LANG, LC_ALL, LC_CTYPE all empty/unset in the CLI's environment

Suspected cause

The paste handler appears to read UTF-8 bytes through an 8-bit codec (Mac Roman) instead of UTF-8. Node's readline defaults to UTF-8, so this likely comes from either:

• an explicit setEncoding/decode in the bracketed-paste codepath that doesn't force 'utf8', or
• a fallback to the OS/locale encoding when LANG/LC_CTYPE are unset (note: the environment above has no UTF-8 locale set, which can push libc/ICU-style codecs toward a legacy default).

Worth checking whether Claude Code sets process.stdin / paste-buffer encoding explicitly to 'utf8', and whether the paste path differs from the typed-input path (it must — typed Unicode works fine).

Related issues

This is the same class of bug as several confirmed paste-in mojibake reports, but all of those are Windows/Linux decoding as Latin-1/CP-1252 with CJK input — this report adds a macOS + Mac Roman + Electron PTY data point with Western punctuation:

• #67421 — paste-in mojibake, Linux agent view, UTF-8→Latin-1 (CJK)
• #65394 — paste-in mojibake, Windows fullscreen renderer, UTF-8→Latin-1 (CJK)
• #65806 — (closed dup) Windows no-flicker renderer, UTF-8→Windows-1252 (CJK)
• #75380 — macOS, same — glyph signature, but the copy-out direction rather than paste-in