Claude CodeのサンドボックスがNixOSで権限エラーになる原因と対処法

NixOSのnix-shellでClaude Codeのサンドボックスを有効にすると、/sandboxパネルの表示はEnabledのままなのに、Bashコマンドだけが軒並み失敗することがあります。原因はbubblewrapではなく、apply-seccompという補助バイナリの実行権限です。npmパッケージが配布したファイルのパーミッションビットが壊れていたことが原因で、実際に解決したのはAnthropicではなくnixpkgsパッケージング側の対応でした。原因の切り分け方とあわせて確認します。

NixOSのnix-shellで有効表示のままBashが全滅する症状

sandbox.enabledをtrueにしたNix環境でClaude Codeを使うと、/sandboxパネルの表示はEnabledのままなのに、Bashコマンドの実行だけが例外なく失敗する構成に当たることがあります。GitHub上のnixpkgsのissueが報告した失敗はこの形です。

/nix/store/dii6cpbdqzjcjqcy18x6n56cql0fmdg9-claude-code-2.1.111/lib/node_modules/@anthropic-ai/claude-code/vendor/seccomp/x64/apply-seccomp: Permission denied
Exit code 126

終了コード126は、ファイルは見つかったものの実行できなかったことを示すシェルの標準的な値です(ファイル自体が見つからない場合は127になります)。原因は表示ではなく、実行の内側にあります。この時点で/sandboxパネル自体はサンドボックスを有効と表示しており、依存関係が欠けているという警告は出ません。報告は2026年4月17日、Claude Code 2.1.111へアップグレードした直後に上がっています。issueの本文は、/sandboxをオンにしてBashツールを一度使わせるだけで再現すると説明しています。

原因はapply-seccompバイナリのパーミッションビット

apply-seccompは、サンドボックス内のBashコマンドにseccompフィルタを掛け、Unixドメインソケットを遮断するための補助バイナリです(v2.1.92のchangelogに同梱の記載があります)。この不具合が報告された当時の構成では、このバイナリの実行に失敗するとBashコマンド全体が起動できませんでした。issueのコメントで、nixpkgsのメンテナーであるoskarwires氏が原因を特定しています。

npmパッケージが配布するtarballの中で、apply-seccompのファイルモードが0644のまま固定されており、実行ビットが立っていませんでした。bashは実行権限のないファイルをexecできず、Permission deniedのまま終了コード126を返します。

バイナリが導入された版については、情報源によって食い違いがあります。oskarwires氏のコメントは2.1.96以降としていますが、Anthropic側のissue報告者は2.1.91までは正常に動き2.1.92から壊れたと述べています。公式changelogのv2.1.92には「Linuxサンドボックスがnpm・ネイティブ双方のビルドにapply-seccompヘルパーを同梱し、Unixソケット遮断を復元した」という記載があります。少なくともこの版で、ヘルパーが両方の配布形態に組み込まれたことは確認できます。

同じ症状は、nixpkgsを経由しないUbuntu/Debian環境でも報告されています。Anthropic側のissue #43367は、nvmでグローバルインストールしたclaude-codeが自動更新のたびに実行権限を失い、chmod +xを毎回打ち直すしかない状態を記録しています。パッケージ配布そのものの不具合であって、Nix特有の問題ではありません。

版をまたいだ経緯 — 導入から解決までのタイムライン

apply-seccompの権限修正はAnthropicでなくnixpkgsパッケージング側が担った

Anthropic側の追跡issue #43367は、修正コミットに結び付けられたわけではありません。2026年5月24日、しばらく動きが無かったことを理由に、GitHub Actionsのbotが自動でクローズしています。つまり、npmパッケージの権限ビットをAnthropicが直したという確認は、このissueからは取れません。

Nix環境で実際に問題を解いたのはnixpkgs側の対応です。PR #511120は、npmのtarballを取り込む代わりに、Anthropicが配布するネイティブバイナリをそのままパッケージする形へ、nixpkgsのclaude-code派生を切り替えています。oskarwires氏はこの変更で「seccomp helperがembedされる」ため、パーミッションの不整合自体が起きなくなったとコメントしています。

修正の実体は、npm配布物の欠陥そのものへの手当てではなく、nixpkgsが依存するパッケージ経路を変えたことにあります。同じapply-seccompという名前のファイルが指すコンポーネントの位置づけも、この間に変わった可能性があります。公式ドキュメントは現在、Linux/WSL2で必須の依存としてbubblewrapとsocatだけを挙げ、apply-seccompが担うseccompフィルタは任意扱いで、役割もUnixドメインソケットの遮断に限定されると説明しています。インストールも本体パッケージとは別のnpm install -g @anthropic-ai/sandbox-runtimeで行う形になっており、本体のnpmパッケージに同梱されたバイナリの権限で全コマンドが道連れになる、という2026年4月の報告とは前提が変わっています。ただし、この変化がいつどの版で入ったかを示す公式changelogの記載は見当たりません。

自分の環境が同じ不整合に当たっているか確認する手順

実際に同じ不整合に当たっているかは、apply-seccompのファイル権限を直接見れば切り分けられます。BashコマンドがExit code 126とPermission deniedで止まったら、エラーメッセージに出たパスをそのままls -lに渡すのが確実です。

# エラーメッセージに出たパスをそのまま渡す
ls -l /path/to/.../vendor/seccomp/x64/apply-seccomp

-rwxr-xr-xではなく-rw-r--r--(モード0644)と表示されれば、このバイナリだけが原因です。claude doctorは一般的なインストール診断コマンドですが、公式ドキュメントを見る限り、このバイナリ権限の食い違いを個別に検出する項目は見当たりません。原因の切り分けはls -lで直接見るほうが確実です。

nix-shellやnixpkgs#claude-code経由でインストールしている場合、恒久的な対処は、使っているnixpkgsのチャンネルやflakeの入力を、oskarwires氏の修正(PR #511120、2026-04-23マージ)より新しいリビジョンへ進めることです。flakeを使っているなら、flake.lockのnixpkgs入力にあるlastModified(UNIXタイムスタンプ)を見れば、pinしているスナップショットがいつのものか分かります。2026-04-23より前の値なら、この修正を含まないリビジョンです。

# flakeの場合
nix flake update nixpkgs
 
# channel運用の場合
nix-channel --update

home-managerやNixOSのシステム設定でチャンネルを固定している場合も考え方は同じで、nixos-rebuild switch --upgradeのようにチャンネル自体を更新してから再ビルドしない限り、古いclaude-code派生を使い続けることになります。更新をすぐに反映できない場合は、サンドボックスそのものを一時的に切って通常の許可プロンプトへ戻すほうが早く復旧します。

{
  "sandbox": {
    "enabled": false
  }
}

sandbox.enabledは既定では設定されておらず、値が無ければサンドボックスは動作しません。書けばBashコマンドは従来どおり許可プロンプトを経由して実行されます。似た名前のsandbox.allowUnsandboxedCommandsはこれとは別の設定で、サンドボックスに阻まれたコマンドをdangerouslyDisableSandboxパラメータで個別に再試行させるかどうかを制御するものです。サンドボックス自体を切る今回の復旧には使えません。

sandbox.failIfUnavailableは既定でfalseのため、依存関係が起動時に見つからない場合は警告を出して素通しします。ただし今回のケースでは、バイナリ自体はディスク上に存在するため、この起動時チェックは働きません。実行時にexecが失敗して初めて問題が表に出ます。これが、/sandboxパネルの表示と実際の挙動がずれる理由です。

似た場面で起きるunshare(CLONE_NEWUSER)のEINVAL失敗や、AppArmorが原因のapply-seccompのsetgroups書き込み失敗は、どちらもエラーメッセージこそ似ていますが原因は別物です。サンドボックス全体の権限モデルはClaude Codeのサンドボックス設計で、Linux環境の準備手順はClaude Code Ubuntuインストールガイドで確認できます。

まとめ

NixOSのnix-shellでClaude Codeのサンドボックスが有効表示のまま失敗するのは、bubblewrapではなくapply-seccompという補助バイナリの実行権限が原因です。npmパッケージが配布したファイルのモードが0644のままだったため、bashがexecできずPermission deniedで落ちていました。

Anthropic側の追跡issueは修正確認のないままstale-botでクローズされており、実際に解決したのはnixpkgsパッケージをネイティブバイナリ配布へ切り替えたoskarwires氏の対応です。自分の環境で同じ不整合に当たっているかは、エラーメッセージに出るパスの権限をls -lで確認すれば切り分けられます。/nix/store配下ならchmodではなくnixpkgsの更新が必要で、それ以外のインストールならchmod +xがその場の対処になります。