Claude CodeのChrome連携がFlatpak版Chromeで動かないときの対処

Flatpak版のGoogle Chrome（com.google.Chrome）を使っていると、Claude Codeの/chromeが「Extension: Not detected」のまま進まないことがあります。拡張機能は入っていて、Chromeも動いている状態です。

原因の候補は2つに分かれます。ネイティブメッセージングのマニフェストがFlatpakの設定ディレクトリに無いこと。そして、マニフェストが指すホストバイナリがサンドボックスの中から見えないことです。前者は設定ファイルのコピーで済みます。後者はflatpak overrideでのアクセス許可が要ります。

Flatpak版Chromeで何が起きているか

Claude Codeは、Chrome連携を初めて有効にしたときにネイティブメッセージングホストの設定ファイルを書き込みます。公式の手順では、Linuxでの置き場所は次のとおりです。

~/.config/google-chrome/NativeMessagingHosts/com.anthropic.claude_code_browser_extension.json

ところがFlatpak版のChromeは、この場所を読みません。Flatpakはアプリに、ホストのファイルをほとんど見せないからです。Flatpakの公式ドキュメントによると、既定で見えるのはランタイム、アプリ本体、~/.var/app/$FLATPAK_ID、$XDG_RUNTIME_DIR/app/$FLATPAK_IDだけです。Chromeにとっての「設定ディレクトリ」は、次の場所に置き換わります。

~/.var/app/com.google.Chrome/config/google-chrome/NativeMessagingHosts/

GitHubのissue #100185（2026年10月7日起票）は、まさにこの状況の報告です。報告者はv2.1.291のLinux環境で、マニフェストが前者にしか書かれず、後者には無いと書いています。さらに、マニフェストが指すホストバイナリ~/.local/bin/claudeもサンドボックスからは届かない、という見立てです。修正されたかどうかは、issueのステータスで確かめられます。

3つ目は通常の切り分けです。手順はClaude Code Chrome接続トラブルにまとめています。ここでは前の2つに絞ります。

まずFlatpak版かどうかを確かめる

Chromeの入れ方で、読まれるディレクトリが変わります。最初に確認します。

flatpak list --app | grep -i chrome
ls ~/.var/app/com.google.Chrome/config/google-chrome/ 2>/dev/null
ls ~/.config/google-chrome/NativeMessagingHosts/

1行目でcom.google.Chromeが出れば、Flatpak版です。2行目は、Flatpak側の設定ディレクトリの存在確認です。3行目は、Claude Codeが書いたマニフェストが標準パスにあるかの確認になります。

Flatpak版でなければ、この記事の症状とは別の原因です。WSLではChrome連携自体がサポート対象外です。起動時に連携を有効にする設定は3キーの記事にありますが、Flatpak側のマニフェストの置き場所はこの設定では変わりません。

標準パス側にだけマニフェストがあれば、issueの症状と一致します。標準パス側にも無いなら、先に/chromeの「Reconnect extension」とChromeの再起動を試します。公式は、初回有効化後にChromeを再起動して設定を読み直させるよう案内しています。

マニフェストをFlatpak側に置く

Chromeのドキュメントによると、ネイティブメッセージングホストのマニフェストはJSONで、name、description、path、type、allowed_originsを持ちます。pathはLinuxとmacOSで絶対パスにします。ブラウザごとの置き場所がパスに現れるため、Claude Codeが書いたファイルをそのままFlatpak側にコピーするのが手早い方法です。手で書き起こすとallowed_originsのIDを写し間違えます。

DEST=~/.var/app/com.google.Chrome/config/google-chrome/NativeMessagingHosts
mkdir -p "$DEST"
cp ~/.config/google-chrome/NativeMessagingHosts/com.anthropic.claude_code_browser_extension.json \
  "$DEST/"
grep '"path"' "$DEST/com.anthropic.claude_code_browser_extension.json"

最後のgrepで、マニフェストが指す実行ファイルのパスが分かります。issueの報告では~/.local/bin/claudeです。このパスが次の手順の対象になります。

Flatpakのドキュメントには、~/.var/app/$FLATPAK_IDの下はアプリが自由に使える領域とあります。コピーしたファイルはそこで読まれます。ただし、Claude Codeが次にマニフェストを書き直したとき（バージョンを切り替えたときなど）、コピーは更新されません。pathが変わるなら、コピーをやり直します。

ホストバイナリをサンドボックスから見えるようにする

マニフェストを置いただけでは足りないことがあります。pathが指す~/.local/bin/claudeは、既定ではサンドボックスの外にあるからです。Flatpakでは、--filesystemで見せるパスを追加できます。ホームの下の任意のパスは~/some/dirの形で指定でき、読み取り専用にするなら:roを付けます。

flatpak override --user --filesystem=~/.local/bin:ro com.google.Chrome
flatpak override --user --show com.google.Chrome

2行目で、追加した許可が反映されたか確認できます。

~/.local/bin/claudeがシンボリックリンクなら、リンク先のディレクトリも見える必要があります。リンクの行き先は次で調べます。

readlink -f ~/.local/bin/claude

出力されたディレクトリも--filesystem=...:roで追加します。許可は必要最小限にします。Flatpakのドキュメントは、静的で恒久的なファイルシステム許可をできるだけ絞ることと、:roによる読み取り専用を勧めています。--filesystem=homeのような広い許可は、Chromeにホーム全体を見せることになります。

許可の広さには段階があります。Flatpakのドキュメントによると、homeはホームディレクトリ全体（~/.var/appを除く）、hostは/以下のほぼ全体を見せる指定です。どちらも今回の目的には広すぎます。同じドキュメントは、フルアクセスの代わりにポータルやXDGの標準ディレクトリを使うことも勧めています。~/.local/binのような特定のパスは、~/some/dirの形でサブパスごと見せられます。見せる範囲をバイナリのあるディレクトリだけに絞れば、Chromeが読めるものを最小限に保てます。

許可を変えたら、Chromeを完全に終了して起動し直します。

それでも動かないときに残る疑い

上の手順で解けるのは、パスの見え方までです。次の点は、公式ドキュメントにもissueにも記載がなく、手元で試して確かめることになります。

• サンドボックス内でホストバイナリが実行できるか。Flatpakアプリはホストとは別のランタイムで動きます。見えるようになったバイナリが、そのまま起動するとは限りません。
• ホスト側のClaude Codeセッションとの通信が成立するか。issueの報告者は、バイナリが「サンドボックスから届かない」とだけ述べていて、届くようにした後の動作までは書いていません。
• Claude Codeの更新でマニフェストが書き直されたとき、Flatpak側のコピーが古くならないか。上で述べたとおり、コピーは自動では追従しません。

2つ目までで詰まるなら、Flatpak版ではないChrome（配布パッケージや公式の.deb、.rpm）に切り替えると、この問題は起きません。公式ドキュメントは、Edgeなど他のChromium系ブラウザについて、同じファイルを各ブラウザ固有の設定ディレクトリから読むと説明しています。Edgeならファイル名は同じで、Linuxの置き場所が~/.config/microsoft-edge/NativeMessagingHosts/になります。Brave、Arc、Vivaldi、Operaも、各ブラウザの設定ディレクトリから読みます。

手動配置で確認する順序

issue #100185のステータスが変わったかどうかは、issueのページで確かめられます。直るまでは、手動配置が現実的な回避策です。確認の順序は次の3点です。

1. lsで、Flatpak側にマニフェストがあるか見る
2. pathが指すバイナリを、flatpak override --user --showの許可で到達できるか確かめる
3. Chromeを完全に再起動し、/chromeの表示が「Extension: Installed」になったか見る

3点目の前に、chrome://extensionsで拡張機能をいったん無効にして有効に戻す方法もあります。Chrome連携ドキュメントの「Browser not responding」の対処にある操作で、拡張機能側の接続を張り直せます。Chrome連携ドキュメントの「Extension not detected」の節には、手動配置の前に見る基本項目として、拡張機能がchrome://extensionsで有効になっていること、claude --versionで確かめたClaude Codeが最新であること、Chromeが起動していることが挙がっています。

3点目が「Installed」にならない場合は、サンドボックス内でのバイナリ実行の問題が残っている可能性があります。そのときはissueにFlatpakのバージョン情報（flatpak info com.google.Chromeの出力）と、/chromeの表示を添えて報告すると、原因の切り分けが進みます。