Claude Code Ubuntuインストール — bubblewrap依存関係の解決

Claude CodeをUbuntu/Linuxで動かす最短ルート

Ubuntu・Debian・Fedoraなど主要なLinuxディストリビューションでは、ターミナルで1行実行するだけでClaude Codeが使えます。

curl -fsSL https://claude.ai/install.sh | bash

このコマンド自体はmacOSやWSL2でも共通です。OS別の全手順はClaude Codeインストール完全ガイドにまとめてあるので、本記事はLinuxならではの1点、サンドボックス機能を動かすためのbubblewrap依存関係に絞って掘り下げます。ここを踏まえずに導入すると、claude コマンド自体は動くのにサンドボックスだけ有効化できない、という中途半端な状態でつまずきやすいためです。

導入前に確認しておきたいこと

インストール自体はシンプルですが、Linux固有の要件を先に押さえておくとサンドボックス周りでの手戻りがなくなります。

サンドボックスはmacOSでは標準のSeatbeltフレームワークを使うため追加インストールが不要ですが、Linux/WSL2では別途2パッケージが要ります。この違いを知らずに「サンドボックスが有効にならない」と困るケースが多く、本記事の中心テーマもここにあります。サンドボックスの設計思想自体はClaude Codeのサンドボックス設計で詳しく扱っているので、ここでは実際にLinux環境で動かすための実務手順に絞ります。

Ubuntu/Debianへのインストール手順

curlによるネイティブインストールがそのままUbuntu・Debianで使えます。

curl -fsSL https://claude.ai/install.sh | bash

サーバー群を構成管理しているなら、署名付きaptリポジトリからの導入も選べます。

sudo install -d -m 0755 /etc/apt/keyrings
sudo curl -fsSL https://downloads.claude.ai/keys/claude-code.asc \
  -o /etc/apt/keyrings/claude-code.asc
echo "deb [signed-by=/etc/apt/keyrings/claude-code.asc] https://downloads.claude.ai/claude-code/apt/stable stable main" \
  | sudo tee /etc/apt/sources.list.d/claude-code.list
sudo apt update
sudo apt install claude-code

インストール後は claude --version でバージョンを確認し、プロジェクトディレクトリで claude を起動してログインします。ここまでは他OSと同じ流れです。問題はこの先で、Linuxではサンドボックスが既定では動かないという点を次の節で解決します。

サンドボックス(bubblewrap)を有効にする

Claude Codeにはシェルコマンドをファイルシステムとネットワークの両面で隔離する「サンドボックス化されたBashツール」が組み込まれています。有効にすると、境界内に収まるコマンドは許可プロンプトなしで自動実行され、開発体験を止めずに安全性を上げられます。ただしLinuxとWSL2では、この機能が2つのパッケージに依存します。

• bubblewrap: ファイルシステム分離を担う非特権サンドボックスツール
• socat: サンドボックスのプロキシ経由でネットワーク通信を中継するリレー

Ubuntu/Debianでは次の1行でインストールできます。

sudo apt-get install bubblewrap socat

Fedoraなら sudo dnf install bubblewrap socat です。ripgrepはネイティブバイナリに同梱されているため別途インストール不要ですが、任意機能のseccompフィルタ(Unixドメインソケットの遮断を追加する)が欲しい場合は npm install -g @anthropic-ai/sandbox-runtime で導入します。

導入したらClaude Codeを再起動してから /sandbox を実行してください。依存関係のチェックは起動時にしか走らないため、パッケージを入れただけでは反映されません。パネルにDependenciesタブしか出ない場合は、ripgrep / bubblewrap / socat / seccompフィルタのうち何が不足しているかがそこに表示されます。

Ubuntu24.04以降でAppArmorがbubblewrapを止める問題

ここがUbuntuユーザーが最も踏み抜きやすい落とし穴です。Ubuntu 24.04以降は既定のAppArmorポリシーが、bubblewrapが隔離に必要とするユーザー名前空間の作成をブロックします。bubblewrapとsocatをインストールしても、この制限のせいでサンドボックスが起動しないことがあります。

まず自分の環境がこの制限の対象かを確認します(WSL2でも同様に確認が必要です)。

sysctl kernel.apparmor_restrict_unprivileged_userns

結果が 0 なら制限は無効なので以降の手順は不要です。No such file or directory エラーが出た場合もキー自体が存在しないため対応不要です。1 が返ってきた場合だけ、bwrapにユーザー名前空間の作成を許可するAppArmorプロファイルを追加します。

sudo tee /etc/apparmor.d/bwrap > /dev/null <<'EOF'
abi <abi/4.0>,
include <tunables/global>
 
profile bwrap /usr/bin/bwrap flags=(unconfined) {
  userns,
  include if exists <local/bwrap>
}
EOF

このプロファイルはbwrap自体にのみ適用され、サンドボックス内で実行されるコマンドには影響しません。作成後はAppArmorをリロードして反映させます。

sudo systemctl reload apparmor

反映後に /sandbox を開き直すと、Dependenciesタブが消えてMode / Overrides / Configの3タブが表示されるようになります。

WSL2・コンテナ環境でのサンドボックスの違い

WSL2上のUbuntuでは基本的にネイティブLinuxと同じ手順が通りますが、2点だけ異なる挙動があります。

WSL1では動きません。bubblewrapはWSL2でしか使えないカーネル機能に依存するため、WSL1ディストリビューションではサンドボックスが機能しません。PowerShellから wsl -l -v でバージョンを確認し、WSL1になっていれば wsl --set-version <ディストリビューション名> 2 でアップグレードします。

Windowsバイナリの起動もひと手間違います。WSL2は cmd.exe やPowerShellなど /mnt/c/ 配下のWindowsバイナリの起動を、Unixソケット経由でWindowsホストに委譲する仕組みを持っています。これをサンドボックス内から許可するかどうかは allowAllUnixSockets の設定次第で、遮断するにはseccompフィルタのインストールが前提になります。

コンテナ環境ではさらに別の問題が起きます。非特権コンテナの中ではbubblewrapが新しい /proc をマウントできず、サンドボックスが起動に失敗します。この場合は enableWeakerNestedSandbox を true にすると、内側のサンドボックスがコンテナが持つ既存の /proc をbind mountして動くようになります。ただしこの設定が想定しているのは、外側のコンテナがすでに十分な隔離境界を提供している場合に限られます。プロセス情報がサンドボックス内のコマンドから見えるようになるため、隔離を弱める側の設定である点は理解した上で使ってください。DevContainerやDocker上でClaude Codeを安全に動かす実装そのものはDevContainerでの安全な実行構成で扱っています。

よくあるつまずき

Linux特有のつまずきは、インストールそのものよりサンドボックスの有効化に集中しています。

パッケージを入れたのにDependenciesタブが消えない

依存関係のチェックはClaude Codeの起動時にしか走りません。apt install の後は必ずセッションを再起動してから /sandbox を開き直してください。

企業のmanaged settingsで起動しなくなった

failIfUnavailable: true をmanaged settingsで指定すると、bubblewrapのようなサンドボックス依存が見つからない場合にClaude Codeの起動自体を拒否するようになります。これは警告付きで隔離なし実行にフォールバックする既定動作を、意図的にハード失敗へ変える設定です。組織で必須化する場合は、対象フリートにネイティブWindowsが含まれないかも合わせて確認します(サンドボックスはネイティブWindowsでは動作せず、WSL2かコンテナ内での実行が前提になります)。

ヘッドレスなUbuntuサーバーでログインできない

ブラウザーが開けないサーバー環境では、ターミナルに出るURLを手元のブラウザーで開いて認可コードを貼り付ける方式が使えます。CI・自動化パイプラインのように対話ログイン自体が難しい場合は、claude setup-token で発行した1年有効なOAuthトークンを環境変数に設定する運用が向いています。自社サーバーでClaude Codeのセッションを継続的に動かす構成はClaude Code self-hosted-runnerにまとまっています。

docker コマンドがサンドボックス内で失敗する

dockerコマンドはサンドボックスと構造的に相性が悪く、常に失敗します。excludedCommands に docker * を追加してサンドボックスの外で実行させます。

よくある質問

サンドボックスを使わずにClaude Codeを使えますか

使えます。サンドボックスは既定で有効ではなく、依存パッケージが無い環境では警告を出したうえで隔離なしの通常実行にフォールバックします。従来どおり各コマンドの実行前に許可を求める運用のままでも問題なく動作します。

bubblewrapのインストールに管理者権限は必要ですか

apt-get install bubblewrap socat の実行自体には sudo が必要ですが、Claude Code本体のインストールやbwrapの実行に管理者権限は要りません。AppArmorプロファイルの追加だけは sudo でファイルを配置する操作です。

Alpine LinuxでもUbuntuと同じ手順で動きますか

パッケージマネージャーが異なるため、bubblewrapとsocatの導入コマンドは apk add bubblewrap socat に読み替えます。またAlpineには素の状態で bash と curl が入っておらず、ネイティブインストールコマンド自体が失敗することがあります。先にこの2つを導入してから進めてください。

WSL2ではないネイティブWindowsでbubblewrapは使えますか

使えません。サンドボックスはmacOS・Linux・WSL2でのみ動作し、ネイティブWindowsは対象外です。Windows環境でサンドボックスを使いたい場合はWSL2上でClaude Codeを動かす構成にします。

まとめ

Ubuntu/LinuxでのClaude Code導入自体はcurlの1行で完了しますが、サンドボックス機能まで含めて動かすには bubblewrap と socat の追加インストールが必須です。Ubuntu 24.04以降ではAppArmorが既定でbubblewrapのユーザー名前空間作成を止めるため、sysctl kernel.apparmor_restrict_unprivileged_userns で確認し、必要ならプロファイルを追加してから systemctl reload apparmor で反映させます。パッケージを入れた後は必ずClaude Codeを再起動し、/sandbox でDependenciesタブが消えたことを確認するのが動作確認の基本です。WSL2やコンテナ環境ではさらに固有の設定が要るので、当てはまる場合はそちらの設定も済ませてから使い始めてください。サンドボックスの権限モデル全体はClaude Codeセキュリティ・権限ガイドを併読すると理解が深まります。