Claude Media
Claude CodeのChromebook貼り付け不具合とDesktopのサインイン保存

Claude CodeのChromebook貼り付け不具合とDesktopのサインイン保存

ChromebookのLinux環境(Crostini)で、Claude Codeの右クリック貼り付けが効かない件と、Claude Desktopのサインインが保存されない件の症状と回避策、効かない操作です。

ChromebookのLinux環境(Crostini)でClaude Codeを使うと、ほかのアプリでは通る右クリック貼り付けが、Claude Codeのプロンプトだけで効かないことがあります。同じ環境にClaude Desktopを入れると、GNOME Keyringが動いているのに「サインインが保存されない」警告が出る報告もあります。

どちらもGitHubのissueで未解決です。ここでは症状の見分け方と、今できる回避策を並べます。Coworkがなぜ起動しないかはChromebookのLinux環境でCoworkが使えない理由にあります。

右クリックで貼り付けられないのはどんな症状か

#82238は、Claude Code 2.1.220でも右クリック貼り付けが効かないという報告です。起票は7月29日で、状態は未解決です。ラベルは area:tui です。

再現手順は短く、次の流れです。

  1. ChromeOSのTerminalアプリを開く
  2. cat や bash で、右クリック貼り付けが通ることを確かめる
  3. claude を起動する
  4. 文字列をコピーし、Claude Codeのプロンプトで右クリックする
  5. 何も貼り付けられない

起票者は、素のシェルでは問題なく貼れると書いています。ChromeOS Terminalの設定(Settings > Keyboard & mouse)にある「Mouse right clicks paste content」を有効にしても直らず、Ctrl+Shift+V も効きません。以前のバージョンでは動いていたと説明しているため、退行として報告されています。

コメントの切り分け表が示すもの

同じissueのコメントに、コピー元と貼り付け先を組み合わせた結果があります。

コピー元貼り付け先結果
ターミナル貼り付け先ChromeOS結果通る
ChromeOS貼り付け先ターミナル結果通る
ターミナル貼り付け先ターミナル結果通る
Claude Code貼り付け先ChromeOS結果通る
Claude Code貼り付け先Claude Code結果通る
ChromeOS貼り付け先Claude Code結果失敗

失敗するのは、ChromeOS側のクリップボードからClaude Codeのプロンプトへ貼る組み合わせだけです。コメントの書き手は、Claude Codeが端末のクリップボードに寄っているように見えると書いています。原因はissueでは特定されていません。

先行の#68620は同じ症状の報告でしたが、修正されないまま「not planned」で自動クローズされています。#82238はその再起票です。

修正を待つあいだに試せること

issueには回避策が載っていません。公式ドキュメントとissueの症状から、現実的な手順を3つ挙げます。どれも効果をissueが確認したものではなく、試す順番の提案です。

方法1: 素のシェルで貼ってファイル経由で渡す

素のシェルでは右クリック貼り付けが通る、という点を使います。長い文字列は、Claude Codeに直接貼らずファイルに落とします。

cat > memo.txt
# ここで右クリック貼り付け、Enter のあと Ctrl+D
claude

Claude Codeを起動したら、プロンプトで @memo.txt のようにファイルを指定します。端末のドキュメントも、非常に長い入力は貼らずにファイルへ書いて読ませる方法を挙げています。800文字超か3行超の貼り付けは、[Pasted text #1 +120 lines] のようなプレースホルダーに畳まれて送られる仕様です。

方法2: マウスの取り込みを切って挙動を比べる

フルスクリーン描画モードは、マウスイベントをClaude Codeの内部で処理します。CLAUDE_CODE_DISABLE_MOUSE=1 を付けると、マウスの取り込みだけが止まり、端末の側が選択を扱います。

CLAUDE_CODE_DISABLE_MOUSE=1 claude

ドキュメントには、クリック処理だけを切る CLAUDE_CODE_DISABLE_MOUSE_CLICKS=1 もあります。こちらは「右クリックと中クリックの貼り付けは、対応する端末で引き続き動く」と書かれています。両方を試して挙動が変わるなら、原因はClaude Code側のマウス処理だと絞れます。

注意点があります。#82238はフルスクリーン描画との関係に触れていません。どちらの変数でも直る保証はなく、直らなければ元の状態に戻すだけです。

方法3: 描画モードを確かめる

/tui を引数なしで実行すると、今のレンダラーが表示されます。/tui default でクラシックな描画に切り替えられます。フルスクリーンを有効にしているなら、一度クラシックに戻して貼り付けを試すと、描画モードとの関係が分かります。

バージョンの観点

changelogには、v2.1.287で「Windows・Linuxの右クリック貼り付けと、Linuxの中クリック貼り付けを、ボタンを離した時点で実行する」変更が入っています。ボタンの上でポインターを動かして離すと、貼り付けは取り消されます。右クリックが一瞬で離れない入力デバイスでは、押し直しが必要です。この変更が#82238の症状とつながるかは、issueでは触れられていません。

Claude Desktopのサインインが保存されないとき

こちらは#77913です。起票は7月15日で、状態は未解決です。公式の.debでClaude Desktopを入れたChromebookで、起動のたびに次の警告が出ると報告されています。

Your sign-in won't be saved on this device. Install and unlock a system keyring (such as GNOME Keyring), then restart the app.

メッセージは、キーリングを入れて解除するよう案内します。ところが起票者の環境ではGNOME Keyringが入っていて、動いていて、解除済みでした。Linux版のトラブルシューティングが挙げる原因(未導入、KDE Plasmaとの競合、ロック)のどれにも当たらない状態です。

起票者が見つけた原因

起票者の説明では、ChromiumのOS暗号化層(os_crypt)がportalバックエンドを選び、その初期化に失敗します。CrostiniではD-Busの org.freedesktop.impl.portal.Secret が呼び出せる名前としては存在するものの、実装がありません。失敗すると、動くはずの gnome-libsecret を試さず、暗号化なしの保存に落ちます。Crostiniが XDG_CURRENT_DESKTOP=X-Generic を設定することも、デスクトップ環境による判定を外す要因として挙げられています。

起票者自身が、調査の大半をClaude Codeに任せたこと、全部は保証できないことを書いています。以下の確認手順は、確度の目安として読んでください。

症状の確かめ方

issueが示す手がかりは2つです。

  • ~/.config/Claude/Local State に、"os_crypt":{"portal":{"prev_init_success":false}} が入っている
  • キーリングに Claude Safe Storage という項目が無い

キーリングそのものが健全かどうかは、D-Busから確かめられます。

gdbus call --session --dest org.freedesktop.secrets \
  --object-path /org/freedesktop/secrets/collection/Default_5fKeyring \
  --method org.freedesktop.DBus.Properties.Get \
  string:org.freedesktop.Secret.Collection string:Locked

(<false>,) が返れば、既定のコレクションは解除済みです。その状態で警告が続くなら、ドキュメントのキーリング導入手順を繰り返しても出口はありません。

回避策は3通り、効くのは条件つき

issueとコメントには、保存を成立させる方法が3つ出ています。

くらべる

3つの回避策の違い

いちばん汎用的

起動フラグ

--password-store=gnome-libsecret を付けて起動します。org.freedesktop.secrets を持つ実装(GNOME Keyring、KDE Wallet、KeePassXCなど)で動きます。

GNOME KeyringかKDE Wallet向け

portals.conf

Secretの経路を明示して、portalを再起動します。バックエンドを持つのはその2つだけです。

副作用が大きい

XDG_CURRENT_DESKTOP

GNOME を値に含めます。ただしQtのテーマ選択とportalの優先順位も変わります。

起票者が実際に確かめたのは、1つ目の起動フラグです。

起動フラグを確実に効かせる

ターミナルから起動する場合は、~/.bashrc に関数を置きます。

claude-desktop() {
    command claude-desktop --password-store=gnome-libsecret "$@"
}

ランチャーのアイコンから開く場合は、デスクトップエントリをユーザー側へコピーし、Exec= に環境変数とフラグを足します。

cp /usr/share/applications/com.anthropic.Claude.desktop \
   ~/.local/share/applications/
sed -i 's|^Exec=claude-desktop|Exec=env XDG_CURRENT_DESKTOP=GNOME claude-desktop --password-store=gnome-libsecret|' \
   ~/.local/share/applications/com.anthropic.Claude.desktop
update-desktop-database ~/.local/share/applications

直ったかどうかは、Claude Safe Storage 項目がキーリングにできたか、警告が消えたか、アプリとVMの再起動後もサインインが残るかで判断します。

フラグが消える・反映されない落とし穴

コメントには、見落としやすい点が3つ報告されています。

  • ウィンドウを閉じただけでは足りない: プロセスが残っていると、再起動が残ったプロセスに吸収されて、新しいフラグが反映されません。完全に終了させてから試します
  • .desktop の書き換えが戻る: 別の環境(Arch系)では、アプリが ~/.local/share/applications/com.anthropic.Claude.desktop を起動時に再生成し、Exec= が元に戻ったという報告があります。Crostiniで同じ挙動かは書かれていません
  • PATHの前に置いたラッパーは残る: /usr/local/bin/claude-desktop に exec /usr/lib/claude-desktop/claude-desktop --password-store=gnome-libsecret "$@" を書く方法は、再生成の影響を受けなかったと報告されています

起動時に再生成される環境では、デスクトップエントリを編集するより、ラッパーを置く側が確実です。

ChromeOSの外でも起きるか

同じissueに、Sway、Hyprland、labwcといったwlroots系の環境での再現報告が並んでいます。XDG_CURRENT_DESKTOP が GNOME でも KDE でもないと、アプリ側の判定が other になり、キーリングを探す分岐がありません。このため、ChromeOS固有の問題とは言えない状況です。Fedora・Archなど公式対応外のディストリビューションでの扱いは、Claude DesktopはFedora・Archで使えるかにまとめています。

症状が出る側は、こう見えます。サインインのCookieは残るのに、トークンの保存だけが失敗するため、「セキュリティ上の理由」で1〜2日おきにマジックリンクでの再ログインを求められる、という報告がありました。「毎回」でも「約1日おき」でも、まず Local State と起動ログの backend=basic_text を探すと、原因が絞れます。再ログインのパターン別の見分け方は、Claude Desktop Linux版で再ログインを繰り返し求められる原因と対処法にあります。

どちらの問題から手を付けるか

貼り付けの問題は、Claude Code側のマウス処理か描画に絞れそうです。まず CLAUDE_CODE_DISABLE_MOUSE=1 で挙動が変わるかを見ます。変わらなければ、素のシェルから貼ってファイルで渡す方法に落とします。

サインインの問題は、キーリングが動いているのに警告が出るかどうかが分かれ目です。出ているなら、キーリングをいじり直すより、起動フラグかラッパーに進む方が早くなります。どちらも、公式の修正が出るまでの暫定対応です。issueの更新を確認して、直った場合はフラグやラッパーを外します。

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