7月25日、grigio.orgが「sandbox-bwrap-nix: A lightweight sandbox for AI agents and experiments」と題した記事を公開した。AIコーディングエージェントをローカルで動かすとき、エージェントが不要と判断したファイルを消したり、ホームディレクトリの設定を書き換えたりするリスクは常につきまとう。この記事が提示する答えは「Dockerもsudoも要らない。bubblewrapとNixだけで十分だ」というものだ。
「エージェントがrm -rfしたらどうする？」という現実問題
Claude CodeやOpenCode、Devinのようなローカル動作型AIコーディングエージェントの普及に伴い、「エージェントにどこまでの権限を与えるか」は実用上の問題として急浮上している。エージェントが意図しないパッケージをインストールしたり、シェルコマンドで重要なファイルを削除したりするリスクは、デモ環境だけの話ではなく、日常的な開発ワークフローに直結する。
対策としてDockerやPodmanを使う手もあるが、どちらもデーモンの起動、イメージのプル、sudo権限が必要で、立ち上げまでに時間がかかる。sandbox-bwrap-nixは、この問題を「namespaceとバインドマウントだけ」でシンプルに解決する。
仕組み：bwrap + Nix、それだけ
sandbox-bwrap-nixの本体は、わずか3つのファイルで構成される。
start-sandbox.sh— エントリポイント。bwrapを適切なフラグで呼び出し、nix developを起動するflake.nix— サンドボックス内で使えるツール群を定義するdevシェルflake.lock— nixpkgsのリビジョンをピン留めするロックファイル
あとはsandbox-homeディレクトリが隔離されたホームとしてマウントされるだけだ。
**bubblewrap**（bwrap）は、Linuxのユーザー名前空間（user namespace）をベースにしたサンドボックスツールで、root権限なしにプロセスを隔離できる。
起動コマンドはこれだけだ。
git clone https://github.com/grigio/sandbox-bwrap-nix
cd sandbox-bwrap-nix
./start-sandbox.sh
起動は1秒以下。デーモン不要、イメージプル不要、root不要。
3層の隔離
サンドボックスは次の3層で保護を実現する。
ファイルシステム層：Nixストア（/nix/store）は読み取り専用でマウントされ、ホームディレクトリはsandbox-homeフォルダに差し替えられる。/tmpは新鮮なtmpfsが割り当てられ、それ以外のホストのファイルシステムはサンドボックス内から見えない。
プロセス層：独自のPID名前空間を持つ。ホストのプロセスとサンドボックス内のプロセスは互いに見えないため、エージェントが他の実行中ソフトウェアに干渉できない。
環境変数層：--clearenvフラグで起動するため、ホストの環境変数は一切引き継がない。APIキーなどの秘密情報が環境変数に含まれていても、漏洩するリスクがない。
何が入っているか
devシェルにはデフォルトで以下のツールが含まれる。
nix/git/gnumakebun（JavaScriptランタイム）uv（Pythonパッケージマネージャ）opencode（AIコーディングエージェント）micro（テキストエディタ）、less、bashInteractive（補完付き）
追加ツールはflake.nixを編集してnix flake updateを実行するだけで導入できる。
sandbox-homeにはgitブランチ情報付きのプロンプトを出す.bashrc、flakesを有効化したnix.conf、そしてopencodeの設定フォルダがあらかじめ用意されている。
Dockerとの比較、そしてトレードオフ
元記事では、nix develop単体との違いも明示している。nix developだけではファイルシステム全体にアクセス可能で、PID名前空間も共有される。sandbox-bwrap-nixを使えば、エージェントが触れるのは許可した領域だけになる。
Dockerとの比較では、Dockerfileもイメージビルドも不要な分だけ軽量だが、Linuxかつbwrapがインストールされた環境に限定され、異なるOSやカーネルは提供しない。
そして見落としがちな重大なトレードオフとして、ネットワークはホストと完全に共有される点がある。ファイルシステムやプロセスは隔離されていても、エージェントは任意の外部エンドポイントへ通信できる状態にある。悪意ある依存パッケージによるデータ送信や、エージェントの誤操作による意図しないAPI呼び出しは、このサンドボックスでは防げない。ネットワークレベルの制御が必要な用途では、別途ファイアウォールルールやnetwork namespaceの追加を検討すべきだ。
前提条件としてNixとFlakesの有効化が必要になる。Nixを使っていないエンジニアにとっては導入コストが発生する。
まとめ
Claude CodeやOpenCodeといったローカル動作型AIエージェントの普及が加速する中、エージェントの権限制御はもはや「念のための対策」ではなく、日常的な開発環境設計の一部になりつつある。sandbox-bwrap-nixは「Linuxのnamespaceで十分」という割り切りのもと、最小限の構成でその問題に答えている。ファイルシステム・プロセス・環境変数の3層隔離は実用に十分だが、ネットワーク分離がない点はリスク評価に織り込んでおく必要がある。リポジトリ全体を数分で読み通せる規模なので、仕組みを把握した上でカスタマイズしやすいのも利点だ。
詳細はsandbox-bwrap-nix: A lightweight sandbox for AI agents and experimentsを参照していただきたい。
