apply-seccompのsetgroups書き込みがLinuxで失敗する原因と対処

Claude CodeのLinuxサンドボックスを有効にすると、すべてのBashコマンドが次のエラーで失敗することがあります。

apply-seccomp: write /proc/self/setgroups (nested userns is capability-restricted; caller must provide CAP_SYS_ADMIN): Permission denied

GitHub Issue #43454は、Claude Code 2.1.92で必須になったapply-seccompヘルパーが、Ubuntu 24.04以降のAppArmor既定ポリシーと衝突して起きる既知の不具合だと報告しています。似た場面で起きるunshare(CLONE_NEWUSER)のEINVAL失敗とは原因も対処も別物で、本記事はこのsetgroups書き込み拒否に絞って扱います。サンドボックスそのものの有効化・無効化の挙動はsandbox.enabledはClaude CodeのBashコマンドを隔離する設定で確認できます。

/proc/self/setgroups書き込みが拒否される仕組み

sandbox.enabledが有効なLinux環境で、Claude Codeはapply-seccompという名前で自分自身を再実行し、ユーザー名前空間(user namespace)を作ってからBashコマンドを起動します。ユーザー名前空間の内側でプロセスの補助グループを操作するには、通常UID/GIDのマッピングより先に/proc/self/setgroupsへdenyを書き込む手順を踏みます。CAP_SYS_ADMINはLinuxのcapabilityの中でも特に広範な操作を許可する特権で、ネストしたユーザー名前空間の内側でこの書き込みを行うにはこの権限が要求されます。Issue本文の再現コマンドは、この書き込みだけを切り出したものです。

# apply-seccompが内部で行っているのと同じパターン
unshare -U bash -c "echo deny > /proc/self/setgroups"
# → Permission denied
 
# 先にUIDマッピングを済ませると成功する
unshare -Ur echo test

報告者のjohanneshauerが切り分けた原因は、Linuxカーネル自体の制限ではありません。kernel.apparmor_restrict_unprivileged_usernsを0にしても症状は変わらず、実際にブロックしているのは/etc/apparmor.d/bwrap-userns-restrictが定義するunpriv_bwrapという子プロファイルです。このプロファイルはaudit deny capabilityでbwrap配下の非特権プロセスからCAP_SYS_ADMINを一律に剥奪しており、apply-seccompヘルパーもこの対象に含まれます。/usr/bin/bwrap自体は別のbwrapプロファイルで動くため単純な起動は成功しますが、その内側で子プロセスとして動くapply-seccompは権限を剥がされます。unshare -U trueのような単純なコマンドは通るのに、setgroupsへの書き込みだけがCAP_SYS_ADMIN不足で弾かれるのはこのためです。

自分の環境がこの不具合に該当するか確認する

エラーメッセージが同じでも原因が違うケースがあるため、AppArmorの監査ログで実際にcapabilityが拒否されているかを確認するのが確実です。

sudo dmesg | grep -i "apparmor.*DENIED.*unpriv_bwrap"

profile="unpriv_bwrap" comm="apply-seccomp" capability=21 capname="sys_admin"という行が出力されれば、本記事で扱っているAppArmorのcapability拒否に該当します。報告はkernel 6.17.0-14、6.17.0-20、6.17.0-22、7.0.0-15の複数バージョンにまたがっており、特定のカーネルビルドに限った不具合ではありません。

v2.1.92でサンドボックスのフォールバックが消えた

この不具合は既存のバイナリが壊れたのではなく、新しいヘルパーの導入で表面化しました。CHANGELOGはv2.1.92の変更点を次のように記録しています。

Linux sandbox now ships the apply-seccomp helper in both npm and native builds, restoring unix-socket blocking for sandboxed commands

報告者のweilhaltが確認したところ、v2.1.91で「動いていた」と見えた環境の多くは、サンドボックス自体が起動していませんでした。当時のLinuxサンドボックスはsocatが入っていないと黙って無効化される作りで、未インストール環境ではBashが素のまま(Seccomp: 0、ユーザー名前空間なし)で実行されていたためです。v2.1.92でapply-seccompヘルパーがsocatの有無に関係なく必ず呼ばれるようになった結果、AppArmorの制限を受けるUbuntu環境では、それまで気づかれていなかったCAP_SYS_ADMIN不足が致命的な起動失敗として表面化しました。

Issueは2026年4月4日に登録され、6月22日のコメントでもUbuntu 26.04・kernel 7.0.0-15・Claude Code 2.1.185(ネイティブインストール)での再現が報告されています。v2.1.278のCHANGELOGにもこの不具合を修正したという記載はありません。

似た症状の別原因と混同しないための切り分け

Issueのコメント欄には、このCAP_SYS_ADMIN拒否とは別の原因による失敗も混ざっています。切り分けを誤ると的外れな対処をしてしまうため、順に確認します。

npmでインストールした環境では、apply-seccompバイナリ自体に実行権限が付いていないケースが報告されています。macOS版のHomebrewインストールでも同じ実行権限の欠落が確認されており、プラットフォーム固有の不具合ではありません。

sudo chmod +x /usr/local/lib/node_modules/@anthropic-ai/claude-code/vendor/seccomp/*/apply-seccomp

ただし報告者のtreboniusは、この実行権限の欠落が今回のCAP_SYS_ADMINエラーの原因ではないと明言しています。ネイティブインストールでは同じ権限の問題自体が起きず、ヘルパーは正常に起動したうえでAppArmorに拒否されているためです。

socatをアンインストールすると症状が消えたという報告もありますが、これは前節のとおりサンドボックス自体を無効化しているだけで、修正ではありません。macOS版で使えるsandbox.network.allowAllUnixSocketsについても、ある報告者はLinux版にはこの回避策自体が存在しないと指摘しています。別の報告者は同じ設定で直ったと述べており、コメント欄の中でも評価が割れたままです。

コンテナ内の「Operation not permitted」とは別問題

Bubblewrapを非特権コンテナの中で動かすと、bwrap: Can't mount proc on /newroot/proc: Operation not permittedという別のエラーで失敗することがあります。これは公式ドキュメントのTroubleshootingが扱う既知の制限で、enableWeakerNestedSandboxをtrueにすると、外側のコンテナが用意した/procをそのままバインドマウントして回避します。エラーメッセージが「Permission denied」ではなく「Operation not permitted」で、かつコンテナの中で発生している場合はこちらの制限に該当し、本記事の対処手順では直りません。

公式ドキュメントが示すAppArmorプロファイルの追加手順

Anthropic公式のサンドボックスドキュメントは、Ubuntu 24.04以降のこの制限に対して、bwrap自体に限定した許可プロファイルを追加する手順を示しています。まず制限の有無を確認します。

sysctl kernel.apparmor_restrict_unprivileged_userns

値が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
sudo systemctl reload apparmor

このプロファイルは/usr/bin/bwrapというパスにだけ適用され、サンドボックス内部で実行するコマンドそのものには影響しません。Issueのコメント欄でこの公式手順を試したという報告は見当たらず、コミュニティはより広い範囲に効く別の回避策に流れています。

Issueコミュニティの回避策と代償

一番上の対策は報告者のweilhaltら複数人が効果を確認していますが、システム全体のbwrapサンドボックスに影響する点は見落とされがちです。個別のコマンドだけをサンドボックス対象外にするsandbox.excludedCommandsでdockerなど非対応コマンドを対象外にするという設定もありますが、この不具合はサンドボックスの起動そのものが失敗するため、特定コマンドを除外しても他のコマンドで同じエラーに遭遇します。

公式の許可はbwrap限定、コミュニティの回避策はサンドボックス全体を緩める

公式ドキュメントの手順は/usr/bin/bwrapというパス単位でしか許可を広げません。一方でコミュニティの回避策はunpriv_bwrapという共有プロファイルそのものを緩めるため、Claude Code以外のbwrapサンドボックスアプリにも影響が及びます。Issueスレッドを追う限り、この違いを意識して公式手順を先に試したという報告は見つからず、実際に効果が確認されているのは影響範囲の広いほうの回避策です。恒久修正の候補としてIssue本文に挙げられている、ヘルパー内での再試行ロジックの追加はanthropic-experimental/sandbox-runtimeのPRとして提出されていますが、v2.1.278のCHANGELOGを見る限りまだ取り込まれていません。他のAIコーディングエージェントがLinux上のサンドボックス実装でどう分離を作っているかはAIコーディングエージェントのサンドボックス実装比較で比較しています。

まとめ

apply-seccomp: write /proc/self/setgroups ... Permission deniedは、v2.1.92で必須になったapply-seccompヘルパーが、Ubuntu 24.04以降のAppArmor既定プロファイルunpriv_bwrapにCAP_SYS_ADMINを拒否されて起きる不具合です。kernel.apparmor_restrict_unprivileged_usernsを0にしても直らず、npmの実行権限やsocatの有無は別の原因なので混同しないよう注意が必要です。公式ドキュメントは/usr/bin/bwrapだけに限定した許可プロファイルの追加手順を示していますが、Issueで実際に効果が確認されているのはbwrap-userns-restrictを直接編集する、より影響範囲の広い回避策です。どちらも試さない場合はsandbox.enabled: falseでサンドボックスを無効化するほかなく、AppArmorが有効なUbuntu環境では根本修正の到着を待つ必要があります。