Claude Media
Claude CodeでRDPのクリップボードが空になる原因と回避
Claude CodeTips

Claude CodeでRDPのクリップボードが空になる原因と回避

RDP越しのWindowsでClaude Codeのマウス選択コピーをすると、ホストのクリップボードが空になる報告があります。OSC 52とPowerShell 5.1のSet-Clipboardの書き込み順序、切り分け、回避をまとめます。

読了目安 約8分

リモートデスクトップ(RDP)の中のWindowsでClaude Codeを動かし、フルスクリーンのTUIでマウス選択すると、手元(RDPホスト)側のクリップボードが空になることがあります。リモート側のアプリには貼り付けられるのに、ホスト側では何も貼れない状態です。

GitHubのissue #101328に再現手順つきで報告されています。状態はopenで、報告時点のバージョンはClaude Code 2.1.296、Windows 11 Pro、Windows Terminal Preview 1.25です。

空になるのはコピーが2回走るから

報告によると、Windows上のClaude Codeはクリップボードを2つの経路で書きます。

  1. ターミナルへOSC 52のエスケープシーケンスを送る
  2. SSHが検出されない限り、powershellを起動してSet-Clipboardで書く

OSC 52は、端末にクリップボード書き込みを頼む仕組みです。Windows Terminalはこれを受け取り、自分でクリップボードに書きます。報告者が取ったクリップボードのログでは、1回のコピーで次の順に書き込みが起きていました。

時刻書き込んだもの形式
10:36:44.151書き込んだものWindows Terminal(OSC 52)形式13,16,1,7
10:36:44.400書き込んだものpowershell.exe(Set-Clipboard)形式49161(DataObject)、13、49171(Ole Private Data)、16、1、7

約250ミリ秒の間隔で、2回目の書き込みが1回目を置き換えています。2回目を行うのがWindows PowerShell 5.1のSet-Clipboardです。報告者の説明では、このSet-ClipboardはOLEクリップボード(WinForms)経由で書き、プロセスはすぐ終了します。

会話

どちらが悪いのか

  1. 後輩

    OSC 52でちゃんと書けているなら、それで終わりではないんですか。

  2. 先輩

    その後にもう一度、PowerShellが書きます。RDPではクリップボードの中身が遅延取得されることがあり、書き込んだプロセスが先に消えていると、ホスト側が取りに行った時点で中身がない、というのが報告者の見立てです。

  3. 後輩

    見立て、ということは確定ではない。

  4. 先輩

    そうです。issueには、2回の書き込みの競合かどうかまでは切り分けていないと書かれています。再現条件と書き込み順のログだけが確かな部分です。

切り分けの材料になるのは、PowerShell 7(pwsh)のSet-Clipboardを単体で実行するとホストに届く、という報告者の対比です。

RDPに限らず起きる副作用

報告には、RDPの外でも出る副作用が1つ書かれています。TUIで1回コピーするたびに、Win+Vのクリップボード履歴へ2件の項目ができます。OSC 52の書き込みとSet-Clipboardの書き込みが、それぞれ履歴に残るためです。

RDPを使っていなくても、Win+Vを開いて同じ文字列が2つ並んでいれば、この2経路書き込みが動いている目印になります。

自分の環境で当てはまるか確かめる

切り分け

RDPでコピーが空になるときの切り分け

  1. QClaude CodeはRDPセッションの中のWindowsで動いていますか?
    答えがいいえのとき

    この記事の症状とは別の原因です。SSH越しならOSC 52の受け付け側を疑います。

    答えがはい
  2. QフルスクリーンTUIでマウス選択したときだけ空になりますか?
    答えがいいえのとき

    /copyや別経路の可能性があります。コピーコマンドの仕様を先に確認します。

    答えがはい
  3. Qリモート側のアプリには貼り付けられますか?
    答えがいいえのとき

    クリップボードそのものに書けていません。RDPの設定でクリップボードのリダイレクトが無効になっていないかを確かめます。

    答えがはい
  4. QWindows Terminalで Shift+ドラッグ して選択したテキストはホストに届きますか?
    答えがいいえのとき

    Windows Terminal側の設定や別の原因も疑います。

    答えがはい

報告された症状と一致します

アプリ内の選択コピーだけが空になり、ターミナル自身の選択コピーは届くなら、報告と同じ型です。以下の回避を試せます。

報告者も、Shift+ドラッグによるWindows Terminal自身のコピーと、PowerShell 7(pwsh)のSet-Clipboardの単体実行は、どちらもホストに届いたと書いています。症状は「Claude Codeが書いたときだけ」に絞られています。

ホスト側で中身を見るには、貼り付け先のエディタのほか、PowerShellで次のように読めます。

Get-Clipboard

空文字が返るか、直前にコピーした別の文字列のままなら、書き込みが届いていません。

回避の選択肢

issue本文には回避策の確認結果は載っていません。載っているのは報告者が提案する修正案で、Claude Code側の変更が必要なものです。

修正案

issueで提案されている修正

  • Windows Terminalでは native write を省く

    WT_SESSIONが設定されていれば、端末がOSC 52を扱えるので、PowerShell経由の書き込みを飛ばす案です。

  • 書き込みをWin32 APIに変える

    OpenClipboardとSetClipboardData(CF_UNICODETEXT)で書く案です。PowerShell 7のSet-Clipboardはこの方式で、Windows PowerShell 5.1のSet-Clipboardはこの方式ではありません。

  • 書き込みを止める設定を設ける

    設定項目か環境変数で、ネイティブのクリップボード書き込みだけを無効にできるようにする案です。

どれも製品側に入ったとはまだ言えません。issueはopenのままで、コメントはありません。duplicateラベルが付いていますが、重複元はissueの本文からは分かりません。

それまでの間、ユーザー側でできることは、選択コピーの経路を変えることです。製品の設定として説明されているものから、効きそうな順に挙げます。

マウスキャプチャを切ってターミナルに選択させる

CLAUDE_CODE_DISABLE_MOUSE=1は、フルスクリーンでのマウス追跡を無効にし、端末本来のコピーオンセレクトを保つための環境変数です。

$env:CLAUDE_CODE_DISABLE_MOUSE = "1"
claude

こうするとアプリ内の選択が発生しないので、Claude CodeからのSet-Clipboardも走りません。選択はWindows Terminalが行うため、報告者が「届く」と確認したShift+ドラッグと同じ経路になります。引き換えに、クリック操作、クリックによる展開、URLのクリック、アプリ内のホイールスクロールは使えなくなります。PgUpとPgDnによるキーボードスクロールは残ります。

選択時の自動コピーを切る

~/.claude.jsonのcopyOnSelectをfalseにすると、マウスで選択してもクリップボードは変わりません。/configの「Copy on select」からも切り替えられます。

{
  "copyOnSelect": false
}

このキーはsettings.jsonでは無視され、~/.claude.jsonにだけ書きます。自動コピーが止まるので、問題の書き込みは選択のたびには起きなくなります。コピーしたいときはCtrl+Shift+cを押します。ただしCtrl+Shift+cによる手動コピーが、同じ2経路の書き込みを通るかどうかは、issueにも製品のドキュメントにも書かれていません。試して、Get-Clipboardで確かめてください。

クラシックなレンダラーに戻す

選択コピーはフルスクリーンのマウス機能の一部です。/tui defaultでクラシックなレンダラーへ戻せば、会話はターミナル本来のスクロールバックに残り、選択はターミナル側で行います。フルスクリーンの利点(ちらつきの少なさ、長い会話でのメモリの安定)は手放すことになります。切り替えの詳細はClaude CodeのTUIフルスクリーンにあります。

どれを選ぶか

くらべる

回避の違い

フルスクリーンは維持

DISABLE_MOUSE=1

端末のネイティブ選択を使います。クリック操作とアプリ内ホイールスクロールを失います。

マウス操作は維持

copyOnSelect=false

自動コピーだけ止めます。手動コピー(Ctrl+Shift+c)の挙動は未確認です。

報告者がホストに届いたと確認したShift+ドラッグと同じ経路になるのは、DISABLE_MOUSE=1の方です。選択をターミナルに任せるので、2経路書き込みには触れません。copyOnSelect=falseは、手動コピーがどの経路を通るか分かっていません。

SSH越しとの違い

報告された原因のコマンド実行は「SSHが検出されない限り」という条件つきです。同じWindowsでもSSHセッションの中ではSet-Clipboardを呼ばず、OSC 52だけを使う想定です。製品のドキュメントでも、SSH越しではOSC 52へフォールバックすると説明されています。

つまりRDPは、リモートでありながらSSHとして検出されない経路です。Claude Codeから見ると「ローカルのWindows」なので、Set-Clipboardが選ばれ、OSC 52と二重に書かれます。SSHでOSC 52が届かないときの切り分けは、別の問題としてClaude Codeのcopyコマンドの使い方に整理してあります。

似た症状との見分け

クリップボードが空になる話は、原因がまったく違うものが混在します。

この症状は、クリップボードが「空」である点と、RDPで起きる点の2つで他と区別できます。中身が違うのではなく、中身がないのです。

報告するときの書き方

すでに起票されているので、新しいissueを立てるより、既存のissueに自分の環境を足すほうが有用です。書くと役に立つ情報は次のとおりです。

  • Claude Codeのバージョン(claude --version)
  • WindowsとWindows Terminalのバージョン
  • RDPクライアントの種類
  • Get-Clipboardの結果
  • CLAUDE_CODE_DISABLE_MOUSE=1にして届くようになったか

最後の項目は、2経路書き込みが原因だという仮説の裏づけになります。

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

関連する記事

Claude Code をもっと見る →