Korean (Hangul) text becomes mojibake when copying assistant output from Cursor's integrated terminal

Description

When running Claude Code CLI inside Cursor's integrated terminal (zsh), Korean (Hangul) text that Claude outputs in its response becomes corrupted (mojibake) when copied from the terminal and pasted elsewhere — including when pasted back into the same Claude Code chat.

Environment

• Claude Code version: 2.1.198
• Terminal: Cursor's built-in integrated terminal (zsh)
• OS: macOS (Darwin 25.5.0)
• Shell locale (confirmed correct): LANG=ko_KR.UTF-8, LC_ALL=ko_KR.UTF-8, LC_CTYPE=ko_KR.UTF-8

Steps to reproduce

1. Run Claude Code CLI inside Cursor's integrated terminal panel.
2. Prompt Claude so it responds with Korean text (Hangul).
3. Select and copy Claude's rendered response text from the terminal (mouse drag selection / copy).
4. Paste the copied text elsewhere — e.g. into a text editor, or back into the same Claude Code chat input.

Expected behavior

The pasted Korean text should be identical to what was displayed (valid UTF-8 Hangul).

Actual behavior

The pasted text is corrupted / mojibake. Example: the Korean word "리뷰" (review) becomes 리뷰 — this specific fragment recovers cleanly by reinterpreting the pasted bytes as Latin-1 and re-decoding as UTF-8, which is the classic signature of UTF-8 bytes being misread as Latin-1 somewhere in the copy pipeline.

However, most of a longer pasted passage does not cleanly reverse this way — many byte runs fail to decode as valid UTF-8 even after the Latin-1 round-trip, suggesting actual byte loss/misalignment during copy, not just a clean single-round encoding misinterpretation. This points toward a wide-character (East Asian Wide) handling bug: Hangul syllables render as double-width in the terminal, and if Claude Code's TUI miscalculates column width vs. byte width when wrapping/scrolling lines, a multi-byte UTF-8 sequence can get split at the wrong byte boundary in the scrollback buffer, corrupting or dropping bytes on copy.

Notes ruling out other causes

• Directly printing Korean text via a plain shell command in the same terminal session (e.g. printf '리뷰 및 보완\n') and copying that works fine — no corruption. This isolates the bug to text rendered by Claude Code's own TUI (its response output / scrollback), not to the terminal emulator's general UTF-8 handling or the shell locale.
• The issue reproduces even when copying Claude's own output and pasting it right back into the same Claude Code chat input (same app, same terminal), ruling out an external clipboard-consumer app as the cause.

Impact

Any Korean (and likely other CJK / wide-character) text output by Claude Code becomes unreliable to copy-paste when working inside Cursor's integrated terminal, which is a common workflow for non-English-speaking users.