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で直接クリップボードに送ると文字化けしないことを確認しています。壊れているのはコピー対象のテキストではなく、クリップボードへ書き込む経路の側です。

原因: 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というターミナルエスケープシーケンスにフォールバックする、とあります。Claude Code開発側(2026-08-15、bcherny)は、ローカルのmacOSセッションでもpbcopyとOSC 52の両方に書き込んでおり、これは公式ドキュメントには書かれていないセーフティネットだと説明しています。コメント投稿者(annexiao)がコードを読んだところでは、pbcopyは完了を待たずに起動されるため2つの書き込みに順序の保証がなく、OSC 52側が後から上書きすると文字化けしたテキストが残ります。

Issueのコメントでは、VS Code 1.123・1.124の統合ターミナルがOSC 52で受け取ったテキストをlatin-1として誤って解釈するバグが原因として挙がっています。VS Codeはこのバグを1.125で修正しました。

コメント投稿者(annexiao)がコードを読んだところでは、Claude Code側にはhasOsc52ClipboardUtf8Bug()という関数があり、TERM_PROGRAM_VERSIONを数値の範囲(1123000〜1125000未満)と比較して該当バージョンかどうかを判定します。Cursorのような派生ターミナルはTERM_PROGRAM_VERSIONにCursor自身のバージョン番号(例: 3.11.13)を報告するため、この範囲判定から外れ、本来出るはずの警告が表示されません。

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

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

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

最初の報告では、文字化けが起きるのはフルスクリーンレンダリングが有効な状態で、かつコピーするテキストに罫線記号(─など)や★のような記号が含まれる場合に限られる、という再現条件が示されていました。ただし1か月後、別の観測者は罫線記号を含まないマウスドラッグのコピーでも文字化けが7回連続で発生したと報告しており、条件はこの2つの組み合わせに限定されない可能性があります。この観測で計測されたバイト数の増加率はCJK文字を含む選択でおよそ1.4〜1.9倍で、latin-1変換によるバイト膨張の計算と整合する値でした。開発側(bcherny)はv2.1.233での検証時、フルスクリーンと罫線記号の相関について、ターミナル側のOSC 52デコーダのバグに起因するものであり、再現の有無は描画負荷が重くなったときにOSC 52の書き込みがpbcopyの後にずれ込むタイミングの問題とみている、という見立てを示しています。

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

今すぐ試せる対処法

最も手間が少ないのは、/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自身のクリップボード書き込みを経由しない回避策もあります。フルスクリーン中にCtrl+oでトランスクリプトモードへ入り、[キーを押すと会話全体がターミナル本来のスクロールバックへ書き出され、Cmd+fやtmuxのコピーモードなどネイティブの検索・選択がそのまま使えます。vキーなら会話を一時ファイルに書き出して$EDITORや$VISUALで開けます。どちらもマウスドラッグ経由の文字化けが起きやすい罫線記号を含む選択に直接効きます。

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

使い分け早見表

効果が大きく手間も少ないのは、ダンプファイルからのpbcopyか、SSH越しならwキーでのファイル書き出しです。

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

GitHub Issue #79482は2026年7月20日に報告され、2026年9月21日に非活動を理由にbotで自動クローズされています。開発側(bcherny)はv2.1.233では再現できなかったと2026年8月15日のコメントで述べ、原因をVS Code側のOSC 52デコーダのバグとClaude Code側の二重書き込みの組み合わせと説明したうえで、修正はターミナル側の更新待ちになっている部分が残ると位置付けています。クローズ直前のコメントでは、報告者自身が/copy単体の文字化けを10回試して再現できなかったと述べる一方、マウスドラッグ経由の文字化けは同じ日にも継続して観測されていました。二重書き込みのコード自体が修正されたという報告は無いままクローズされているため、特定のバージョンで修正済みと確認できる状態ではありません。

まとめ

Claude Codeの/copyやマウスドラッグでのコピーで日本語や絵文字が文字化けする場合、原因はUTF-8のバイト列がlatin-1として読み直されクリップボードへ書き込まれることにあります。/copyが書き出すダンプファイル自体は文字化けしていないため、pbcopyで直接読み込めば回避できます。SSH越しの接続ではwキーでのファイル書き出しが同様に有効です。VS Code系の統合ターミナルを使っている場合はバージョンの更新も有効な対処になりますが、Issueは修正の確認がないままクローズされているため、環境ごとに実際の貼り付け結果を確認しながら対処法を選ぶことになります。