Claude CodeがGNOME Terminalでコピーできない原因と回避策
GNOME TerminalでClaude Codeの出力を選んでもコピーできない原因は、マウスキャプチャとOSC 52の不達です。Shiftドラッグや /copyなど使える手段を挙げます。
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がマウスイベントを受け取るため、端末側の選択が作られません。
- OSC 52でのコピーが端末に捨てられる。OSC 52は端末へクリップボード書き込みを頼むエスケープシーケンスです。
- 代替画面(alternate screen)を使うため、過去の出力が端末のスクロールバックに残りません。
公式docsの側でも、全画面レンダラーは代替画面に描画してマウスイベントをClaude Code内で処理すると説明されています。ドラッグで作る選択は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では、更新後に全画面モードを試すよう促されて受け入れたところ、それ以来マウスでコピーできなくなったという報告が出ています。以前は普通に使えていた人ほど、原因が「レンダラーの切り替わり」だと気づきにくい構図です。
まず試す: Shiftを押しながらドラッグする
いちばん軽い回避は、端末に選択を任せる方法です。公式docsは、ネイティブ選択のキーを端末ごとに挙げ、GNOME Terminalのような「その他の端末」には Shift を案内しています。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 claudeCLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 は、公式docsでは保存済みの tui 設定にかかわらずクラシックレンダラーを強制する変数として書かれています。毎回付けるのが面倒なら、/tui default で設定を保存する手があります。
{
"tui": "default"
}このキーは ~/.claude/settings.json に書けます。issue #62462では、"tui": "fullscreen" を消すだけでUbuntuとAlmaLinuxの両方でコピーが直り、戻すと再発したという検証が報告されています。
ただし /tui default は万能ではありません。同じスレッドに、/tui default でも直らず、他の挙動が変わるので回避策にならないという反対意見があります。効くかどうかは環境しだいです。
確実に取り出す: /copyとファイル出力
マウス選択に頼らない手段もあります。/copy はClaude Codeプロセス自身がクリップボードへ書き込むコマンドで、コードブロックを1つ選んでコピーすることもできます。公式docsによると、コピー内容をファイルにも書き出してパスを表示します。クリップボードへの書き込みが端末に届かない場合の逃げ道です。
ただし、SSH経由やVTE端末では /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-pasteHELLO と出れば、端末はOSC 52を受け付けています。空のままなら、その端末ではOSC 52経由のコピーは届きません。報告では、PtyxisとGNOME Terminalで空、kitty、foot、WezTermでは HELLO になるとされています。X11では wl-paste を xclip -o -selection clipboard などに読み替えます。
Waylandのwl-copyが空振りするケース
ローカルで使っていても、OSC 52だけが原因とは限りません。公式docsによると、LinuxのローカルセッションではWaylandなら wl-copy、X11なら xclip か xsel を呼び、クリップボードとPRIMARY selectionの両方に書きます。SSH先ではOSC 52に切り替わります。
#80184の報告者は、Claude Code 2.1.217のバンドルを読んだ結果として、wl-copy の呼び出しが完了を待たれず、終了コードも見られていないと指摘しています。加えて、Waylandではコピー元のプロセスが生きている間だけ選択が保たれるため、2秒のタイムアウトで打ち切られるとクリップボードが取り出せなくなる、という分析です。セッション最初のコピーは、ツール検出だけで終わって何もしないとも書かれています。「1回目は空振りし、2回目以降で入ることがある」という間欠的な症状は、この説明と整合します。
これは報告者の解析であり、Anthropicの確認済み事実ではありません。手元で試すなら、次の点を確認してください。
wl-clipboard(X11ならxclipかxsel)がインストールされているかwl-copyを手で実行してwl-pasteで読み戻せるか- 選択直後に
Ctrl+Shift+Cを押し直すと変わるか
copyOnSelect を切り、Ctrl+Shift+C で手動コピーにする構成は、公式docsにある使い方です。ただし #80184は、全画面レンダラーがこの設定を参照しないという別issue(#77259)にも触れています。設定を変えても挙動が変わらないときは、そのissueの影響を疑えます。
症状別の見分け方
| 症状 | 報告された条件 | 効いた手 |
|---|---|---|
| ドラッグ後にハイライトが消え、貼り付けは前の内容 | 報告された条件全画面レンダラー、GNOME Terminal | 効いた手Shift ドラッグ |
| 「copied」と出るのにクリップボードが空 | 報告された条件VTE系(Ptyxis含む)、Wayland | 効いた手Shift ドラッグ |
| SSH先で1画面ぶんしか選べない | 報告された条件代替画面、VTE | 効いた手CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 |
| 中クリック貼り付けが効かない | 報告された条件Fedora 43の全画面 | 効いた手/tui default(効かない例もあり) |
直った報告と、まだ再現する報告
時期によって状況は変わっています。#62462では、Claude Code 2.1.142で最初の報告があり、v2.1.220で /tui fullscreen を試した参加者が「選択して中クリック貼り付けも Ctrl+Shift+C も動く」と書いています。一方、#93147は2.1.266での報告で、GNOME Terminal 3.56.2では再現しています。
3件のissueはいずれもopenのままです。環境(WaylandかX11か、ローカルかSSHか、端末は何か)で結果が分かれるため、「更新すれば直る」とは言えません。#80184はWaylandの wl-copy を呼ぶ処理にも問題があると指摘しており、ローカル利用でも起き得ます。
まとめ
GNOME Terminalでコピーできないのは、全画面レンダラーがマウスを捕捉し、しかもOSC 52がVTEで受け付けられない組み合わせだからです。手軽なのは Shift ドラッグ、長い出力を扱うなら CLAUDE_CODE_DISABLE_MOUSE=1、スクロールバックまで戻すなら CLAUDE_CODE_DISABLE_ALTERNATE_SCREEN=1 です。
全画面レンダラー自体の仕組みはClaude CodeのTUI(フルスクリーン)とはで扱っています。macOSのiTerm2で同じOSC 52の壁に当たったときはiTerm2のOption keyとクリップボードの設定が参考になります。GNOME Terminalは /terminal-setup の対象外で、Shift+Enter の扱いも別問題になります。その対処はterminal-setupコマンドでShift+Enterが効かないときの対処にあります。出力が固まる別の症状はCLAUDE_CODE_NONBLOCKING_STDOUTの記事にまとめています。