Claude Media
Claude CodeでX11のCtrl+Z後にPRIMARY選択が貼れない原因と回避
Claude CodeTips

Claude CodeでX11のCtrl+Z後にPRIMARY選択が貼れない原因と回避

X11でマウス選択をコピーしたあとCtrl+Zを押すと、中クリック貼り付けが空振りします。xclipが一緒に止まる仕組みと、setsidシムなどの回避策を示します。

読了目安 約10分

Linux/X11でClaude Codeのマウス選択をコピーし、Ctrl+Z で一時停止すると、シェルでの中クリック貼り付けが効かなくなります。Ctrl+Shift+V などCLIPBOARD側の貼り付けは動きます。壊れるのはPRIMARY選択だけです。

fg でClaude Codeを再開すれば貼り付けは元に戻ります。原因は、コピーを担う xclip がClaude Codeと同じプロセスグループにいて、Ctrl+Z で一緒に止まることだと、issue #104696の報告者が突き止めています。

症状: 中クリックだけが貼れなくなる

再現手順は3つです。

  1. Claude Codeの画面でマウスをドラッグして文字列を選択する
  2. Ctrl+Z を押してシェルに戻る
  3. シェルのプロンプトで中クリックする

何も貼られません。同じ文字列をCLIPBOARDから貼る操作(Ctrl+Shift+V など)は通ります。報告の環境はClaude Code 2.1.309、Linux 6.17、X11上のi3、Ghostty 1.3.2-dev、zsh、xclip 0.13です。

この報告は報告者個人の観察です。ほかの端末やウィンドウマネージャーで同じように起きるかは、issue上で検証されていません。

原因: xclipがclaudeと同じプロセスグループにいる

公式ドキュメントによると、ローカルセッションでの選択コピーは、Linuxでは wl-copy(Wayland)か xclip・xsel(X11)のうち入っているものを呼び出します。クリップボードとPRIMARYの両方へ書くので、中クリック貼り付けが使えます。

ここでX11の選択の仕組みが効いてきます。X11の選択は、データを保存する場所ではなく「持ち主のプロセスが、要求のたびに渡す」方式です。xclip は一般に、入力を受け取るとバックグラウンドに残って選択の持ち主になります(この動作はissueには書かれていない一般的な挙動です)。持ち主が止まると、貼り付けの要求に誰も答えられません。

issueが示す事実は次のとおりです。

  • コピー時に xclip -selection clipboard と xclip -selection primary の2本が起動する
  • 起動時のオプションに detached も setsid も付いていない(報告者が2.1.309の圧縮済みコードを読み、要旨を書き写したもの)
  • そのため xclip はclaudeのフォアグラウンドのプロセスグループに入る

Ctrl+Z はターミナルがフォアグラウンドのグループ全体へ SIGTSTP を送ります。claudeと一緒に xclip も止まります。

報告者が200ミリ秒間隔で取った状態の記録は、次のとおりです(PGIDはclaudeのもの)。

時刻claudexclip(primary)タイミング
11:13:57claudeSl+xclip(primary)S+タイミングコピー直後
11:14:05claudeTlxclip(primary)TタイミングCtrl+Z で両方が停止
11:14:18claudeRl+xclip(primary)S+タイミングfg で両方が再開

T は停止状態です。両方が同時に止まり、同時に動き出しているため、グループ全体への停止信号が原因だと読めます。

なぜCLIPBOARDは貼れるのか。この点はissueに説明がありません。報告されているのは「CLIPBOARDの貼り付けは動く」という観察だけです。クリップボードマネージャーがCLIPBOARDの中身を引き取って保持している可能性はありますが、報告者の環境で確かめた記述はないため、ここでは推測にとどめます。

自分の環境で同じ症状か切り分ける

再現したら、停止中に別の端末から xclip の状態を見ます。

ps -o pid,pgid,stat,args -C xclip

STAT 列が T で、PGID がclaudeのものと同じなら、報告と同じ状況です。claude側のPGIDは次のように並べて比べられます。

ps -o pid,pgid,stat,args -C xclip,claude

xclip が見つからない場合は、別の原因を疑います。xsel を使っている環境や、Waylandの wl-copy では、このissueの範囲外です。Waylandでコピー後にクリップボードを取り出せない別の症状はGNOME Terminalでコピーできない原因にまとめています。

コピーの経路を知っておくと、避け方を選びやすい

どの経路でクリップボードに書かれるかは、環境で変わります。公式ドキュメントの説明は次のとおりです。

  • ローカルセッション: macOSは pbcopy、Linuxは wl-copy(Wayland)か xclip・xsel(X11)、Windows/WSLはPowerShellの Set-Clipboard
  • tmuxの中: 上に加えてtmuxのペーストバッファにも書く
  • SSH越し: OSC 52のエスケープシーケンスで端末に渡す

このissueに当たるのは、最初の経路のうちX11でxclipが選ばれたときだけです。選択のたびにコピーされる設定(Copy on select)は /config で切り替えられ、既定ではマウスのボタンを離した時点でコピーされます。切ると手動コピーになり、Ctrl+Shift+c で書き込みます。kittyキーボードプロトコルに対応する端末(kitty、WezTerm、Ghostty、iTerm2)では Cmd+c も使えます。

手動コピーなら、Ctrl+Z の直前にコピー操作を済ませる運用にできます。ただし、コピー時に xclip が同じプロセスグループで起動する点は変わりません。PRIMARYの持ち主が止まる問題そのものは、手動コピーに切り替えても残ります。

/copy コマンドは、直近の応答や1つのコードブロックをクリップボードへ書き、コピーした内容をファイルにも保存してパスを表示します。クリップボードへの書き込みが届かない場合の逃げ道になります。ただし /copy が xclip をどう起動するかは、公式ドキュメントにもissueにも記載がありません。Ctrl+Z との組み合わせで同じ症状が出るかは、前節の ps で確かめてください。

回避策: 4つの選択肢

1. 貼る前にfgで戻る

最も手軽な方法です。Ctrl+Z の前にコピー内容をほかの場所へ貼り終えるか、fg で再開してから貼ります。再開すると xclip も動き出すので、PRIMARYは元に戻ります。

2. CLIPBOARD側の貼り付けを使う

症状が出るのはPRIMARYだけです。中クリックの代わりに、端末のペーストショートカットを使えば貼れます。

3. xclipを別セッションで起動させるシムを置く

報告者が効果を確かめた方法です。PATHの前方に、setsid 経由で本物の xclip を呼ぶスクリプトを置きます。

mkdir -p ~/.local/bin
cat > ~/.local/bin/xclip <<'SH'
#!/bin/bash
exec setsid /usr/bin/xclip "$@"
SH
chmod +x ~/.local/bin/xclip

/usr/bin/xclip は例です。本物のパスは command -v xclip で調べ、シム自身を指さないようにしてください。自分を呼び出すと無限に再帰します。~/.local/bin がPATHの /usr/bin より前にあることも必要です。

setsid は呼び出し元と別のセッションを作るので、xclip はclaudeのプロセスグループから外れ、Ctrl+Z の停止信号が届きません。報告者はこのシムを置くと、Ctrl+Z 後もPRIMARYの貼り付けができたと書いており、原因がプロセスグループにあることの裏づけにもなっています。

4. マウス捕捉をやめてターミナルのネイティブ選択を使う

CLAUDE_CODE_DISABLE_MOUSE=1 を設定すると、選択はターミナル自身が扱います。選択はClaude Codeの中ではなく端末の選択バッファに残るため、xclip は起動しないと考えられます。ただしクリック操作とホイールスクロールも使えなくなります。この変数の影響範囲はTUI(フルスクリーン)の解説にあります。クリックだけを止める変数もあり、その挙動はCLAUDE_CODE_DISABLE_MOUSE_CLICKSで扱っています。

シムが効いているか確かめる

シムを置いたら、次の3点で確かめます。

command -v xclip

出力が ~/.local/bin/xclip なら、シムが先に解決されています。/usr/bin/xclip が出るなら、PATHの順序かシェルの設定の読み込みを見直します。claudeを起動し直さないと、古いPATHのまま動いていることもあります。

次に、Claude Codeでテキストを選択してコピーし、別の端末で ps -o pid,pgid,stat,args -C xclip,claude を実行します。xclip のPGIDがclaudeと違えば、プロセスグループから外れています。最後に Ctrl+Z で止めて中クリックし、貼り付けられれば完了です。fg で戻す前に、ps の STAT が T でないことも見ておくと確実です。

停止信号を手で送って、持ち主の仕組みを確かめる

Claude Codeを使わなくても、PRIMARYの持ち主が止まると貼れなくなることは確かめられます。xclip 自身で選択を作り、そのプロセスを手動で止める手順です。

echo "primary-test" | xclip -selection primary
pgrep -x xclip   # 複数のPIDが出たら、最後に起動したものを選ぶ
kill -STOP <上で出たPID>

kill -STOP のあとに中クリックしても、primary-test は貼れないはずです。kill -CONT <PID> で再開すると貼れるようになります。持ち主が止まると要求に答えられない、というX11の仕組みどおりの動きで、Ctrl+Z がやっているのはこの STOP の一括送信にあたります。

この手順はissueの記録(xclip が T になり、fg で戻る)と同じ構造ですが、Claude Codeの内部動作を直接確かめるものではありません。再現そのものは、前節の ps で xclip の PGID を見る方法が確実です。

似た症状との見分け方

「コピーしたのに貼れない」には原因がいくつかあり、このissueが当てはまるのは一部です。

症状当てはまるか見る場所
Ctrl+Z の前は貼れて、後だけ貼れない当てはまるか当てはまる見る場所ps で xclip が T か
Ctrl+Z と無関係に、コピーが空になる当てはまるか別の原因見る場所マウス捕捉とOSC 52(GNOME Terminalの記事)
SSH先で貼れない当てはまるか別の原因見る場所ローカルの端末がOSC 52を受け付けるか
xclip も xsel も入っていない当てはまるか別の原因見る場所ヘルパーのインストール

公式ドキュメントでは、SSH越しのセッションは端末へOSC 52を送り、tmuxの中では追加でtmuxのペーストバッファにも書くと説明されています。どちらもX11のヘルパーを使う経路ではないので、このissueの症状とは切り分けて考えます。

修正の方向と、いま分かっていないこと

報告者が提案する修正は、xclip の起動を detached: true か setsid でclaudeのフォアグラウンドのグループの外へ出すことです。シムはこの修正の疑似的な再現にあたります。

分かっていないことも残ります。

  • 公式ドキュメントの Ctrl+Z の説明は「プロセスをシェルへ中断する。再開は fg」で、ヘルパーの扱いには触れていません
  • /copy コマンドが同じヘルパーを同じ方法で起動するかは、issueに記載がありません
  • 2.1.309より前のバージョンでも起きるかは、報告者自身が「分からない」としています
  • issueの状態はopenで、コメントもなく、修正の予定や担当は示されていません

更新で直るかどうかは、issueのstateとChangelogを見て判断することになります。

まとめ

Ctrl+Z で止まるのは claude だけではなく、同じプロセスグループの xclip です。X11のPRIMARYは持ち主が動いている間しか貼れないため、中クリックだけが空振りします。急ぐなら fg で戻すかペーストショートカットを使い、毎回避けたいなら、報告者が効果を確かめた手段は setsid のシムです。

この記事を共有:XはてブLinkedIn

関連する記事

Claude Code をもっと見る →