Claude Codeの/copyで日本語が文字化けする原因と対処法

Claude Codeの/copyやマウスでのドラッグ選択で、日本語や絵文字を含む応答をコピーすると、貼り付け先で文字化けすることがあります。原因はクリップボードへの書き込み処理でUTF-8のバイト列がlatin-1として再解釈されることで、コピー元のテキスト自体は壊れていません。GitHub Issueに記録された技術的な原因と、今すぐ試せる対処法をまとめます。

何が起きているのか

症状は「表示は正しいのに貼り付けると壊れる」という形で現れます。GitHub Issue #79482の報告者は、好了，给你两条路という中国語の応答を/copyでコピーすると好äºï¼ç»ä½ 两æ¡è·¯という文字列が貼り付けられることを示しています。日本語や中国語などのCJK文字、絵文字、アクセント付きラテン文字などが対象で、ASCII文字だけの応答では発生しません。罫線記号はフルスクリーン時に起きやすい条件として挙がっていましたが、後の観測では必須ではありませんでした。

/copyは実行するたびに応答を/tmp/claude-*/response.mdへダンプしており、この報告ではダンプファイルの中身は正常なUTF-8でした。pbcopy < response.mdで直接クリップボードに送ると文字化けしません。壊れているのはコピー対象のテキストではなく、クリップボードへ書き込む経路の側です。

壊れているのがどこかを切り分ける

貼り付け先のアプリが原因なのか、クリップボードの中身がすでに壊れているのかは、バイト数の比較で分かれます。報告者もこの方法で原因を突き止めています。

wc -c "$(ls -t /tmp/claude-*/response.md | head -1)"
pbpaste | wc -c

latin-1往復の予想値は、手元のPythonで計算できます。好了，给你两条路は8文字で24バイト、latin-1として読み直して再びUTF-8にすると48バイトになります。

python3 -c 'b="好了，给你两条路".encode(); print(len(b), len(b.decode("latin-1").encode()))'

24 48

CJK文字だけならちょうど2倍になり、ASCII文字が混ざるぶん倍率は下がります。Claude Code開発側が再現確認に使った好了，给你两条路 ★ ─────────── café — résuméは81バイトで、同じ変換を通すと150バイトです。倍率は約1.85倍で、後述するマウスドラッグ側の実測値(1.4〜1.9倍)と同じ範囲に収まります。

原因: UTF-8がlatin-1として再エンコードされる

報告者はコピー後のクリップボードのバイト数を計測し、原因を特定しています。ダンプファイルは2,372バイトのクリーンなUTF-8でしたが、実際のクリップボードは4,109バイトでした。この値は「UTF-8のバイト列を1バイト1文字のlatin-1として読み直し、それを再びUTF-8としてエンコードし直す」という変換の結果と正確に一致します。CJK文字は本来UTF-8で3バイトですが、この変換を経ると1文字が3つのlatin-1文字として扱われ、再エンコード後は6バイトに膨らみます。

Claude Codeは、ローカルセッションではネイティブのクリップボードツール(macOSのpbcopyなど)でクリップボードへ書き込みます。SSH越しの接続ではOSC 52というターミナルエスケープシーケンスにフォールバックします。

VS Code 1.123・1.124の統合ターミナルには、OSC 52で受け取ったテキストをlatin-1として誤って解釈するバグがありました。VS Codeは1.125で修正しています。開発側の説明では、pbcopyの後からOSC 52の書き込みが着くと、正しい内容が壊れた内容で上書きされます。報告者が取り出したOSC 52のペイロード(915バイト)は、ダンプファイルとバイト単位で一致していた、とあります。ただしこれは文字化けしなかった/copy実行での観測です。

Claude Codeには、VS Code 1.123・1.124に対する警告が入っています。ただしCursorのような派生ターミナルはCursor自身のバージョン番号(例: 3.11.13)を名乗るため、警告の条件から外れます。報告者が使ったCursorのビルドはVS Code基盤のバージョンとして1.125.0を示していましたが、報告者自身は「修正が入っている証拠にはならない」と書いています。

開発側は修正方針として2つを挙げています。ネイティブのクリップボード書き込みが成功した場合に、VS Code系のターミナルではOSC 52への書き込みをローカルでスキップする案と、Cursorへ警告を拡張する案です。

マウスドラッグでの選択でも同じ現象が起きる

/copyコマンドだけでなく、ターミナル出力をマウスでドラッグして選択するコピーでも同じ文字化けが起きます。フルスクリーンレンダリング中のマウス操作はClaude Code自身が処理しており、選択したテキストは/copyと同じクリップボード書き込みの経路をたどります。フルスクリーンレンダリングの仕組みはClaude CodeのTUI(フルスクリーン)とはにまとめています。

最初の報告に続く追記では、文字化けが起きるのはフルスクリーンレンダリングが有効な状態で、かつコピーするテキストに罫線記号(─など)や★のような記号が含まれる場合に限られる、という再現条件が示されていました。報告の約1か月後に当たる8月17日、報告者は別の観測を載せています。20分間のマウスドラッグで文字化けが7回起き、うち6回は罫線記号を含まない選択でした。バイト数の増加率は1.39〜1.92倍で、latin-1変換による膨張の計算と整合します。同じ時間帯のドラッグにはきれいにコピーできたものもあり、条件は罫線記号とフルスクリーンの組み合わせに限られません。

開発側はv2.1.233での検証時、フルスクリーンと罫線記号の相関について、描画負荷が重いとOSC 52の書き込みがpbcopyの後にずれ込むタイミングの問題とみています。ターミナル側のデコーダのバグが根にある、という見立てです。

なお、マウスドラッグでのコピーには行末に余分な空白が混入する別の不具合もあります。これは文字化けとは異なる症状で、原因と対処法はClaude Codeのコピペで余分なインデントが付く問題と対処法にまとめています。/copyのコードブロック選択画面を省く設定はcopyFullResponseの使い方にあります。

今すぐ試せる対処法

最も手間が少ないのは、/copyが書き出すダンプファイルから直接クリップボードへ流し込む方法です。

ダンプファイルから直接pbcopyする

/copyはコピーの実行時に応答を一時ファイルへ書き出しています。このファイル自体は文字化けしていないため、クリップボードコマンドで直接読み込めば正しいテキストを取得できます。

pbcopy < "$(ls -t /tmp/claude-*/response.md | head -1)"

/tmp/claude-*/の*部分には環境ごとの番号が入ります(報告者の環境ではclaude-501)。複数のダンプファイルが残っているとワイルドカードのままpbcopy <に渡してもファイルを1つに絞れないため、ls -tで最新の1件に確定してから読み込みます。Linuxではpbcopyをwl-copyやxclipに置き換えられますが、ダンプ先が同じ/tmp/claude-*/になるかはmacOSでの報告に基づくものなので、実行環境でls /tmp/claude-*/を見てから使うのが安全です。

SSH越しではwキーでファイルに書き出す

SSH越しの接続ではOSC 52がそもそもの転送経路になるため、latin-1変換の影響を受けやすくなります。/copyのピッカーでwキーを押すと、クリップボードを経由せずリモートのファイルシステムへ直接書き出せます。この経路はクリップボード転送そのものを迂回するため、文字化けの原因になっている書き込み処理を経由しません。詳しい手順はClaude Code copyコマンドでコードブロックだけを送る、SSH接続自体の設定はClaude Code SSH接続ガイドにまとめています。

VS Code系の統合ターミナルを最新版に更新する

VS CodeやCursorなどの統合ターミナルを使っている場合、ターミナル側のバージョンを確認します。VS Code 1.125以降ではOSC 52の解釈バグが修正されているため、対象バージョンより古ければ更新が有効な対処になります。Cursorのような派生ターミナルは自前のバージョン番号を持つため、VS Code本体のバージョンとは別に確認が必要です。

コピー直後のトーストでどの経路が使われたか確認する

Claude Codeはコピーのたびに、どの経路でクリップボードへ書き込んだかをトースト通知で表示します。ネイティブのクリップボードツール・tmuxのペーストバッファ・OSC 52のいずれが使われたかがこの通知で分かります。文字化けが起きたときはまずOSC 52経由だったかを見ると、次にどの対処法が合うかの判断材料になります。

iTerm2やTerminal.appなどローカルのターミナルに切り替える

開発側は、現行のVS Codeビルド(1.125以降)かTerminal.app・iTerm2であればきれいに貼り付けられるはずだとしています。ただし前述のとおり、ローカルセッションでもpbcopyとOSC 52の両方が動くため、切り替えても必ず解消するとは限りません。実際に貼り付けて確かめるのが安全です。

修飾キーを押しながらドラッグして、ターミナルのネイティブ選択を使う

マウスドラッグのコピーには、Claude Codeの書き込みを通さない経路があります。ターミナルごとに決まったキーを押しながらドラッグすると、選択をターミナル自身が処理し、Cmd+Cなどの通常のコピー操作がそのまま使えます。

常にネイティブ選択を使うなら、CLAUDE_CODE_DISABLE_MOUSE=1でマウスの取り込み自体を切れます。ちらつきのないレンダリングは保たれますが、クリックでのカーソル移動・クリックでの展開・URLクリック・ホイールスクロールは使えなくなります。

フルスクリーンのトランスクリプトモードでネイティブ選択を使う

Claude Code自身のクリップボード書き込みを経由しない回避策もあります。フルスクリーン中にCtrl+oでトランスクリプトモードへ入り、[キーを押すと会話全体がターミナル本来のスクロールバックへ書き出され、Cmd+fやtmuxのコピーモードなどネイティブの検索・選択がそのまま使えます。vキーなら会話を一時ファイルに書き出して$EDITORや$VISUALで開けます。どちらもClaude Codeの書き込みを通らないため、マウスドラッグで起きる文字化けを避けられます。

なお、/copy自体がクリップボードに何も書き込めない(貼り付けても空か以前の内容のまま)場合は、文字化けとは別の症状です。iTerm2は既定でターミナルからのクリップボードアクセスをブロックしており、Settings → General → Selectionの「Applications in terminal may access clipboard」を有効にする必要があります。/terminal-setupを実行すると自動で有効になります。

使い分け早見表

この不具合は解決したのか

GitHub Issue #79482は、2026年9月21日に非活動を理由にbotで自動クローズされました(状態はnot planned)。経過は次のとおりです。

Claude Code側がどのバージョンで直ったかは示されていないため、VS Codeなどターミナル側の更新と、上の対処法の併用が現実的です。

まとめ

文字化けが起きたら、まずダンプファイルとクリップボードのバイト数を比べると、Claude Code側の書き込み経路の問題か貼り付け先の問題かが分かります。前者なら、ダンプファイルからのpbcopyかトランスクリプトモード、SSH越しならwキーが、環境に左右されにくい回避策です。コピー直後のトーストがOSC 52経由を示していたなら、ターミナル側のバージョンを疑う順序になります。