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

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

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

sandbox.enabledをtrueにしたNix環境でClaude Codeを使うと、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

報告は2026年4月17日、Claude Code 2.1.111へアップグレードした直後に上がりました。issueの本文は、/sandboxをオンにしてBashツールを一度使わせるだけで再現すると説明しています。貼られたログには、/sandboxのトグルはenabledなのにseccompのバイナリが実行できない、というClaude自身の説明も残っています。

エラーの出し方にも手がかりがあります。Permission deniedとExit code 126が並んでいれば、ファイルはあるのに実行できない状態です。ファイル自体が無い場合はNo such file or directoryで127になります。

手元で同じエラーを再現する

終了コードの違いは、一時ディレクトリで実行ビットを外したファイルを作れば、サンドボックスを使わずに確かめられます。

printf '#!/bin/sh\necho ok\n' > apply-seccomp
chmod 644 apply-seccomp && ls -l apply-seccomp
bash -c './apply-seccomp'; echo "exit=$?"
bash -c './nothing'; echo "exit=$?"
chmod 755 apply-seccomp
bash -c './apply-seccomp'; echo "exit=$?"

macOS上のbashで実行した出力は次のとおりです。

-rw-r--r--@ 1 user  wheel  18 apply-seccomp
bash: ./apply-seccomp: Permission denied
exit=126
bash: ./nothing: No such file or directory
exit=127
ok
exit=0

モード0644のときだけ126になり、実行ビットを立てると通ります。issueに貼られたエラー文も、同じ形のメッセージです。

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

apply-seccompは、サンドボックス内のBashコマンドにseccompフィルタを掛け、Unixドメインソケットを遮断するための補助バイナリです。v2.1.92のchangelogには、Linuxサンドボックスがnpm・ネイティブ双方のビルドにこのヘルパーを同梱し、Unixソケット遮断を復元したと書かれています。

nixpkgsのissueでは、issueで担当者として名指しされた人物がコメントで原因を特定しました。npmのtarballがapply-seccompをモード0644で配布しており、bashが実行を拒否していたという内容です。担当者はこれを上流のバグと位置づけ、Anthropic側のissue #43367を参照しています。

導入された版については、情報源で数字が食い違います。nixpkgsのissueのコメントは2.1.96からとしています。Anthropic側のissue報告者は、2.1.91まで正常で2.1.92から壊れたと書いています。v2.1.92のchangelogの日付は2026年4月4日で、issue #43367が立った日と同じです。ヘルパーが両方の配布形態に入ったのはこの版なので、報告者の記述のほうがchangelogと噛み合います。

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

導入から解決までのタイムライン

Nix環境のapply-seccomp権限問題はnixpkgsのパッケージ変更で解消した

issue #43367には修正コミットが結び付けられていません。npmパッケージの権限ビットをAnthropicが直したかどうかは、このissueからは判断できません。

Nix環境の問題を解いたのは、PR #511120です。nixpkgsのclaude-codeを、npmのtarballからネイティブバイナリのパッケージへ切り替えました。nixpkgsのissueを閉じたコメントは、ネイティブバイナリ配布がseccompヘルパーを内包するため、tarballの権限問題が起きなくなったと述べています。

修正の実体は、npm配布物の欠陥そのものへの手当てではなく、nixpkgsが依存するパッケージ経路を変えたことにあります。権限の誤りがそのまま残った版でも、ネイティブ配布経由なら影響を受けません。

サンドボックスの前提もこの間に変わっています。公式ドキュメントは、Linux/WSL2で必須の依存としてbubblewrapとsocatだけを挙げます。seccompフィルタは任意で、役割はUnixドメインソケットの遮断だけです。導入はnpm install -g @anthropic-ai/sandbox-runtimeで行う形です。本体パッケージの同梱物の権限で全コマンドが道連れになる2026年4月の報告とは、説明の枠組みが違います。

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

実際に同じ不整合に当たっているかは、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は一般的なインストール診断コマンドで、claude --helpの説明も「Claude Codeのヘルスチェック」にとどまります。バイナリの権限を個別に調べる項目はコマンドの説明に書かれていないので、ls -lで直接見るほうが確実です。

環境ごとの直し方

どこにインストールされているかで、手が届く対処が変わります。

nixpkgsを使っている場合は、チャンネルやflakeの入力がPR #511120のマージより新しいかを確かめます。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の既定値はfalseで、値が無ければサンドボックスは動作しません。/sandboxパネルでモードを選ぶと、このキーはそのプロジェクトの.claude/settings.local.jsonに書き込まれます。切るときは~/.claude/settings.jsonだけでなく、このプロジェクト側のファイルも見ます。

nixpkgsのissueの報告者は、サンドボックスを外した実行ではビルドが通った、と書いています。サンドボックスを外す経路は、公式ドキュメントに載っています。Claudeがコマンド単位でdangerouslyDisableSandboxパラメータを付けて再試行する仕組みです。これを許すかどうかはsandbox.allowUnsandboxedCommandsで決まり、既定値はtrueです。

値をfalseにした厳格モードでは、このパラメータは無視されます。/sandboxのOverridesタブでは「Strict sandbox mode」と表示される状態です。組織が厳格モードを強制している環境では、コマンド単位の回避ができません。権限の修正かサンドボックスの無効化かの二択になります。

sandbox.failIfUnavailableは別の設定です。既定値はfalseで、依存関係が欠けてサンドボックスを起動できないとき、サンドボックスなしでコマンドを実行します。trueにすると、起動時にエラーで終了します。

公式ドキュメントでは、/sandboxの依存関係タブがripgrep・bubblewrap・socat・seccompフィルタのうち欠けているものを並べます。nixpkgsのissueのログには、/sandboxのトグルがenabledのままだったと書かれています。

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

まとめ

Exit code 126とPermission deniedがapply-seccompのパスで出たら、ls -lで実行ビットを見るのが最短です。/sandboxの表示がEnabledのままでも、この症状の切り分けには使えません。見るのはls -lの結果で、/nix/store配下ならnixpkgsを更新し、$HOME配下ならchmod +xで足ります。