Claude Codeでコピペできない原因と回避策 — GNOME Terminalの場合

Claude Codeの画面でコピペできないときは、ネイティブ選択のキーを押しながらドラッグして選び直すのが最短です。GNOME Terminalなど大半の端末は Shift、iTerm2は Option、Terminal.appは Fn です。

GNOME TerminalでClaude Codeの返答をマウスで選び、Ctrl+Shift+C を押しても貼り付けられない。画面には「N characters copied」と出るのに、クリップボードは前のままです。この症状はUbuntu 24.04、Fedora 43、Debian 13、PtyxisなどVTE系の端末で報告されています。

原因は端末の故障ではなく、全画面レンダラーが有効なときのマウス処理にあります。回避の近道は、Shift を押しながらドラッグするか、マウスキャプチャを切るかの2つです。

コピーできない原因は3つの挙動の重なり

GitHubのissue #93147(GNOME Terminal 3.56.2 / VTE 0.80.1、Claude Code 2.1.266での報告)は、症状を3つに分解しています。

ドラッグで作る選択はClaude Codeの内側にあり、端末の選択バッファには存在しません。

厄介なのは2つ目です。報告者は、有効なOSC 52をGNOME Terminalのptyに直接書き込んでもクリップボードは変わらず、kittyでは設定されることを確かめています。それでもClaude Codeは sent 2088 chars via OSC 52 のように成功を表示します。クリップボード設定を疑って時間を失う原因がここです。

なぜ突然コピーできなくなったのか

全画面レンダラーは、最近のClaude Codeでは既定になり得ます。公式docsの表では、フィーチャーフラグを取得するセッションで2026年5月6日以降に初めて使い始めた場合は全画面で起動します。tui 設定を保存している場合はその値が優先されます。

issue #62462では、更新後に全画面モードを試すよう促されて受け入れたところ、それ以来マウスでコピーできなくなったという報告が出ています。フィーチャーフラグを取得しないセッション(Bedrock、Vertex AI、Foundry、テレメトリ無効)でも、そのマシンの初回起動がv2.1.239以降なら全画面になります。起動ダイアログの提案を止めたマシンはクラシックのままです。

以前は普通に使えていた人ほど、原因が「レンダラーの切り替わり」だと気づきにくい構図です。

まず試す: Shiftを押しながらドラッグする

いちばん軽い回避は、端末に選択を任せる方法です。公式docsは、ネイティブ選択のキーを端末ごとに挙げています。GNOME Terminalを含む大半の端末は Shift、Terminal.appは Fn、iTerm2は Option です。VS CodeとCursorは Shift で、macOSでは terminal.integrated.macOptionClickForcesSelection を有効にすると Option も使えます。Shiftを押したままドラッグすると、Claude Codeを経由せず端末が選択を作ります。あとは通常どおり Ctrl+Shift+C でコピーします。

issue #80184(Ptyxis 48.5、Fedora 42)の報告者も、この方法を「確実に効く回避策」としています。ただし限界があります。選択できるのは表示中の1画面ぶんです。#93147の報告では、VTEがShift付きドラッグでオートスクロールしないため、画面外へは広げられません。

長い出力は次の2手のほうが向いています。

根本から避ける: マウスキャプチャと全画面をオフにする

マウスキャプチャだけを切る設定が用意されています。全画面レンダラーの描画と一定のメモリ使用量は残したまま、端末の選択が復活します。

CLAUDE_CODE_NO_FLICKER=1 CLAUDE_CODE_DISABLE_MOUSE=1 claude

代償は、クリックでのカーソル移動、クリックでの展開、URLクリック、Claude Code内でのホイールスクロールが使えなくなることです。PgUp、PgDn、Ctrl+Home、Ctrl+End によるキーボードスクロールは動きます。ホイールだけ残したいなら CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1(v2.1.195以降)があります。ただしこちらはマウスを捕捉し続けるため、ネイティブ選択には結局Shiftドラッグが要ります(止まる操作の範囲)。

スクロールバックも欲しいなら、代替画面そのものを避けます。#93147の報告者は次の組み合わせで、通常のスクロールバックと端末主導の選択が戻ったとしています。

CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 CLAUDE_CODE_DISABLE_MOUSE=1 claude

CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 は、保存済みの tui 設定にかかわらずクラシックレンダラーを強制する変数です。クラシックに戻す役目を担うのは CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN で、CLAUDE_CODE_DISABLE_MOUSE の対象は全画面レンダラーのマウス追跡です。毎回付けるのが面倒なら、/tui default で設定を保存する手があります。

{
  "tui": "default"
}

tui キーはどの設定ファイルにも書けるため、~/.claude/settings.json でも動きます。issue #62462では、"tui": "fullscreen" を消すだけでUbuntuとAlmaLinuxの両方でコピーが直り、戻すと再発したという検証が報告されています。

ただし /tui default は万能ではありません。同じスレッドに、/tui default でも直らず、他の挙動が変わるので回避策にならないという反対意見があります。効くかどうかは環境しだいです。

確実に取り出す: /copyとファイル出力

マウス選択に頼らない手段もあります。/copy はClaude Codeプロセス自身がクリップボードへ書き込むコマンドで、コードブロックを1つ選んでコピーすることもできます。公式docsによると、コピー内容をファイルにも書き出してパスを表示します。ピッカーで w を押せば、クリップボードの代わりにファイルへ書き出せます。クリップボードへの書き込みが端末に届かない場合の逃げ道です。

ただし、SSH経由では /copy もOSC 52頼みになります。docsは、SSH先では /copy が端末に届いたかどうかにかかわらず Copied to clipboard と表示すると明記しています。表示を信用せず、貼り付けて確かめてください。

ファイルに出してしまう運用も安定します。Claude Codeに「この内容を notes.md に書いて」と頼めば、あとは通常のエディターで開いてコピーできます。issue #62462の報告者は、別のタブで claude -p "質問" を実行し、出力を端末の通常の出力として得る手も挙げています。

代替画面のせいで過去の出力を選べないときは、トランスクリプトモードが使えます。Ctrl+o で入り [ を押すと、会話全体が端末のネイティブスクロールバックに書き出され、Cmd+f やtmuxのコピーモードなど端末側の手段で扱えます。Esc か q で全画面に戻ります。

端末がOSC 52を受け付けるか確かめる

OSC 52が原因かどうかは、Claude Codeを使わずに切り分けられます。#80184に載っている手順です(Waylandで wl-clipboard が入っている場合)。

wl-copy --clear
printf '\033]52;c;%s\007' "$(printf 'HELLO' | base64 -w0)"
wl-paste

1行目の printf が端末へ送るのは、次のバイト列です。

printf '\033]52;c;%s\007' "$(printf 'HELLO' | base64 -w0)" | od -c

0000000 033   ]   5   2   ;   c   ;   S   E   V   M   T   E   8   =  \a

ESC ] 52 ; c ; の c がクリップボードの指定で、続く SEVMTE8= が HELLO のbase64です。末尾の BEL(\a)で終わります。

HELLO と出れば、端末はOSC 52を受け付けています。空のままなら、その端末ではOSC 52経由のコピーは届きません。報告では、PtyxisとGNOME Terminalで空、kitty、foot、WezTermでは HELLO になるとされています。X11では wl-paste を xclip -o -selection clipboard などに読み替えます。OSC 52を受け付けない端末はVTE系だけではありません。SSH向けのトラブルシューティングには、iTerm2は設定を有効にするまで無視し、Terminal.appは非対応と書かれています。

Waylandのwl-copyが空振りするケース

ローカルで使っていても、OSC 52だけが原因とは限りません。公式docsによると、LinuxのローカルセッションではWaylandなら wl-copy、X11なら xclip か xsel を呼び、クリップボードとPRIMARY selectionの両方に書きます。SSH先ではOSC 52に切り替わります。

#80184の報告者は、Waylandではコピー元のプロセスが生きている間だけ選択が保たれるのに、コピー後に wl-copy のプロセスが残らず、クリップボードの中身を取り出せないと報告しています。「1回目は空振りし、2回目以降で入ることがある」という間欠的な症状も挙がっています。

これは報告者の観察であり、Anthropicの確認済み事実ではありません。手元で試すなら、次の点を確認してください。

• wl-clipboard(X11なら xclip か xsel)がインストールされているか
• wl-copy を手で実行して wl-paste で読み戻せるか
• 選択直後に Ctrl+Shift+C を押し直すと変わるか

copyOnSelect を切り、Ctrl+Shift+C で手動コピーにする構成は、公式docsにある使い方です。このキーは ~/.claude.json に書く設定で、settings.json に書いても無視されます。全画面レンダラーがこの設定を無視する不具合(#77259)も、v2.1.206で報告されています。

症状別の見分け方

直った報告と、まだ再現する報告

#62462、#80184、#93147の3件はいずれもopenのままです。環境(WaylandかX11か、ローカルかSSHか、端末は何か)で結果が分かれるため、「更新すれば直る」とは言えません。#80184はWaylandでコピー後にクリップボードを取り出せない症状を報告しており、ローカル利用でも起き得ます。X11で Ctrl+Z の後だけ中クリックが貼れない症状は別の機序です。

まとめ

コピーの頻度が高いなら、Shiftドラッグを毎回押すより CLAUDE_CODE_DISABLE_MOUSE=1 を常用する構成のほうが手間は少なくなります。コピー先が端末に届くか怪しい環境では、/copy を併用する選択肢があります。

全画面レンダラー自体の仕組みはClaude CodeのTUI(フルスクリーン)とはで扱っています。macOSのiTerm2で同じOSC 52の壁に当たったときはiTerm2のOption keyとクリップボードの設定が参考になります。GNOME Terminalは /terminal-setup の対象外で、Shift+Enter の代わりに Ctrl+J、または \ を打ってからEnterを使います。その対処はterminal-setupコマンドでShift+Enterが効かないときの対処にあります。出力が固まる別の症状はCLAUDE_CODE_NONBLOCKING_STDOUTの記事にまとめています。