Claude Desktop Linux版のリンクがSnapブラウザで開かない原因

Ubuntuの既定ブラウザであるSnap版Firefoxを使っていると、Linux版Claude Desktopの会話内リンクをクリックしても何も起きないことがあります。エラーも出ません。原因は、アプリ本体のプロセスにNoNewPrivsフラグが立っていて、子プロセスのxdg-openがsnap-confineを起動できないことです。

GitHubのIssue #102029は、Ubuntu 26.04.1 LTSとClaude Desktop 2.37337.1の組み合わせでの再発を報告しています。自分の環境で同じ状態かを確かめる方法と、当面の逃げ道を順に示します。

リンクが無反応になる原因はNoNewPrivsにある

Issue #102029の報告環境は次のとおりです。

症状は単純です。会話内のリンクをクリックしても、ブラウザが開きません。右クリックでリンクをコピーし、ブラウザに貼り付ければ開けるので、リンク先やネットワークの問題ではありません。

NoNewPrivsとは何か

no_new_privsは、Linuxカーネルが持つプロセス単位のフラグです。カーネルのドキュメントによると、一度立てるとfork、clone、execveをまたいで子プロセスに引き継がれ、取り消せません。立っている間は、setuid・setgidビットがUID・GIDを変えず、ファイルケイパビリティも許可セットに加わりません。

Snapアプリの起動に使うsnap-confineは、まさにこのファイルケイパビリティに頼っています。Issueの診断では、getcap /usr/lib/snapd/snap-confineにcap_dac_override,cap_sys_admin,...=pが並び、snap-confine自体は正しく入っていました。それでも、フラグのせいで特権が付かず、起動に失敗します。

アプリ内からxdg-open https://example.comを実行すると、次のエラーが出ると報告されています。

snap-confine is packaged without necessary permissions and cannot continue
required permitted capability cap_dac_override not found in current capabilities:
  cap_wake_alarm=i

Claude Desktopはリンクを開くときxdg-openを使うため、同じ失敗がそのままリンク無反応として現れます。Issueの記述では、xdg-openの失敗はアプリ側に表示されません。

どこでフラグが立つのか

Issueの診断では、メインの--startupプロセスを含むclaude-desktopの全プロセスで/proc/<pid>/statusのNoNewPrivsが1でした。親のsystemd --userは0です。したがって、ログインセッションから引き継いだのではなく、アプリ本体か起動経路が立てていることになります。

自分の環境で当たっているか確かめる

確認は、Claude Desktopの内側と外側で同じコマンドを比べるのが手早い方法です。Codeセッションの端末パネルなど、アプリが起動したシェルは内側にあたります。通常のターミナルを新しく開けば外側です。

# アプリの本体プロセス(1なら立っている)
grep NoNewPrivs /proc/$(pgrep -o claude-desktop)/status
 
# いま操作しているシェル(アプリ内の端末なら引き継ぎを確認できる)
grep NoNewPrivs /proc/$$/status
 
# Snap版ブラウザを直接起動できるか
xdg-open https://example.com

アプリ本体がNoNewPrivs: 1で、アプリ内の端末からxdg-openが上のsnap-confineエラーになるなら、この記事の症状です。外側のターミナルでxdg-openが通るなら、問題はアプリの起動経路に限られます。

当面の回避策

Issueに書かれている、確実に動いた方法は次の2つです。

コピー貼り付けは確実ですが、毎回の手間が増えます。Snap版ではないブラウザを既定にすればsnap-confineを通らないため、フラグの影響を受けないと考えられますが、Issueはこの方法を検証していません。

アプリ内でxdg-openを使う場面だけを救うなら、次のような形です(<url>は開きたいアドレスに置き換えます)。

systemd-run --user --collect /snap/bin/firefox "<url>"

一度直ったのに戻った経緯

この件は再発です。関連する2つのIssueを時系列で並べると次のとおりです。

#102029の報告者は、インストール後にアプリを起動し直しており(インストール9時26分、起動9時34分)、古いプロセスが残っていたわけではないと書いています。

#100854の報告では、2.26454.2と2.19675.1に戻しても症状が変わらず、トリガーはアプリのバージョンよりOSアップグレードだろうと推測されていました。そのうえで修正は2.31226.1で入ったとされ、さらに新しい2.37337.1で再発しています。修正がどの仕組みで入ったかはコメントに書かれていません。

sudoが使えない症状も同じ根

#100854では、アプリの端末パネルでsudoが失敗する症状も同時に報告されていました。メッセージはsudo: The "no new privileges" flag is set, which prevents sudo from running as root.です。no_new_privsはsetuidを無効にするため、同じ根から別の形で表に出ます。

つまり、リンクが開かなくなったときは、端末パネルでsudo trueが通るかも見ておくと、同じフラグの影響かどうかを判断できます。sudoがno new privilegesのメッセージで止まるなら、Snapを使っていなくても同じフラグの影響です。

影響はリンクだけでは済まない

#100854の報告によれば、フラグを引き継ぐのはリンクを開くxdg-openだけではありません。Codeセッション、Bashツール、端末パネルのタブといった、アプリが起動する子プロセスすべてが対象です。

Claude Codeのセッションの中で、Snap版のコマンドや、sudoが必要な手順を実行させる使い方をしている場合は、リンクより先にそちらで失敗します。たとえばバックアップスクリプトをsudoで走らせるタスクを任せたとき、権限エラーではなくno new privilegesのメッセージで止まります。no new privilegesの文面で止まったら、権限設定より先にフラグを疑うと切り分けが早くなります。

アプリの外のログインシェルから起動したClaude Code CLIは、親のNoNewPrivsが0なら通常この影響を受けないはずです。同じマシンでCLIでは動くのにデスクトップ版のセッションでだけ動かない処理があれば、grep NoNewPrivs /proc/$$/statusを両方で実行して見比べると確かめられます。

systemd-runと既定ブラウザ変更の注意点

systemd-runはアプリ内のリンクをクリックしたときの動作を変えません。あくまで、アプリの外から自分でブラウザを起動する手段です。クリック動作そのものを直すには、アプリ側の更新を待つことになります。

既定ブラウザを変えるときは、現在の設定を先に控えておくと戻せます。

xdg-settings get default-web-browser

出力がfirefox_firefox.desktopのようにsnap由来の名前なら、この記事の前提と一致します。別のブラウザに切り替えて試す場合も、うまくいかなければこの値に戻せます。

修正案と、追い方

#102029の報告者は、xdg-openを直接呼ぶ代わりに、XDGデスクトップポータルのorg.freedesktop.portal.OpenURI.OpenURIをD-Bus経由で呼ぶ案を出しています。ポータルはアプリの外で動き、ユーザーの既定ブラウザを起動するため、フラグを引き継がないというのが理由です。もう一つの案は、systemd-run --user経由で起動することと、xdg-openが失敗したときにそれらへ切り替えることです。

Issueは2026-10-14に起票されたもので、bug、platform:linux、regression、area:desktopのラベルが付いています。起票時点でコメントはありません。修正されたかどうかは、Issueの状態と、次のアプリ更新後に先ほどのコマンドを再度実行して見るのが確実です。

アプリ更新は、アプリ内の端末ではなく外側のターミナルで実行してください。アプリ内の端末ではsudoが同じフラグで失敗します。

sudo apt update && sudo apt upgrade
grep NoNewPrivs /proc/$(pgrep -o claude-desktop)/status

更新後は、アプリを完全に終了して起動し直してから確認してください。古いプロセスが残っていると、値が更新前のままになります。#102029の報告者も、インストール後に起動したプロセスであることを時刻で示したうえで再発を報告しています。

別の症状と間違えないために

Linux版Claude Desktopの不具合は、似た見え方で別の原因のものがあります。リンクが開かない症状と、以下は別件です。

アプリの要件は、Claude Codeのドキュメントでは、Ubuntu 22.04以降かDebian 12以降のDebian系ディストリビューションです。Fedoraなど非Debian系は対象外なので、そちらではCLIでの代替を検討することになります。インストール手順自体はLinux版のインストール手順にまとめています。

なお、claude://リンクでアプリを起動する側の仕組みは、ここで扱う「アプリから外のブラウザを開く」向きとは逆です。claude://リンクの記事は、外からアプリを呼ぶ方向を扱っています。

まとめ

リンクが開かない原因はリンクでもネットワークでもなく、アプリ本体が立てたNoNewPrivsがsnap-confineの起動を妨げていることです。/proc/<pid>/statusで1かどうかを見れば、数秒で当たりか外れかが決まります。

当たりなら、リンクのコピー貼り付けかsystemd-run --userで逃げられます。再発しているため、アップデートのたびに一度確認する価値があります。