基礎で扱った権限の仕組みは「実行前にユーザに確認を取る」設計だった。サンドボックスはその一段下のレイヤーで、OS レベルで bash の実行範囲を物理的に制限する。承認疲れの根本対策として、また Claude にもう一段自由を与えるための仕組みとして、フロントイア最初の話題に置く。

なぜサンドボックスか

毎回の bash 実行ごとに承認を求める従来モデルには問題がある:

  • 承認疲れ ─ 10 回目の Yes は内容を見ていない
  • 生産性の低下 ─ 中断が積み重なる
  • 自律性の制限 ─ 承認待ちで Claude が止まる

サンドボックスはこれらに**「事前に境界を定義する」**で答える。Claude Code は定義された境界内で自由に動け、境界外への試みは OS レベルでブロックされる ── というモデル。

仕組み: 二つの分離

サンドボックスはファイルシステムとネットワークの両方を OS プリミティブで分離する。

ファイルシステム分離

  • 書き込み: 現在の作業ディレクトリとそのサブディレクトリのみ
  • 読み取り: コンピュータ全体 (一部の拒否ディレクトリを除く)
  • 拡張: sandbox.filesystem.allowWrite で追加パスを許可

OS レベルなので、Claude のツールだけでなく kubectl terraform npm などすべてのサブプロセス に同じ制限が効く。

ネットワーク分離

  • 承認されたドメインのみにアクセス可能
  • 新規ドメインのリクエストは許可プロンプト
  • カスタムプロキシでルール拡張可

ファイル分離だけでは不十分 ── 攻撃者が SSH キーを抜き出してもネットワークが開いていれば外に送れる。両方を併用するのが必須である。

OS レベルの実装

OS実装
macOSSeatbelt (組み込み、追加インストール不要)
Linux / WSL2bubblewrap
WSL1サポート外

Linux / WSL2 では事前にパッケージをインストールする必要がある。

# Ubuntu / Debian
sudo apt-get install bubblewrap socat

# Fedora
sudo dnf install bubblewrap socat

有効化

/sandbox コマンドで対話的に有効化できる。

/sandbox

メニューでサンドボックスモードを選ぶ。依存関係 (bubblewrap など) が足りなければインストール手順を表示する。

サンドボックスモード

二つのモードがある:

モード動作
自動許可モードサンドボックス内で実行できる bash コマンドは確認なしで自動実行
通常許可モードサンドボックス内でも標準の許可フローを通す (より慎重)

両モードともサンドボックスの制限自体は同じ。違うのは「サンドボックス化されたコマンドを自動承認するか手動確認か」だけ。

自動許可モードでは、編集モードが「編集を受け入れる」でなくても、サンドボックス境界内でファイルを変更する bash コマンドはプロンプトなしで通る ── これが承認疲れの根本対策になる。

設定: 追加パスの許可

kubectl terraform npm などが、プロジェクト外への書き込みを必要とする場合は sandbox.filesystem.allowWrite で例外を作る。

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build"]
    }
  }
}

OS レベルで効くので、子プロセスにも自動的に同じ許可が伝わる。

設定: 読み取りの絞り込み

機密ディレクトリ (例: ~/.ssh、ホームディレクトリ全体) からの読み取りをブロックすることもできる。

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "denyRead": ["~/"],
      "allowRead": ["."]
    }
  }
}

これでホーム以下は読めないが、現プロジェクトディレクトリは読めるようになる。プロンプトインジェクションが起きてもホームディレクトリは触れない、という強い保証が得られる。

互換性のないコマンド

すべてのコマンドがサンドボックスで動くわけではない:

  • watchman ─ サンドボックス内で動かない。jest を使うなら --no-watchman を併用
  • docker ─ サンドボックスとの相性が悪い。excludedCommands で docker * をサンドボックス外に逃がす
  • WSL2 での Windows バイナリ (cmd.exe powershell.exe など) ─ サンドボックスがブロックする

互換性のないコマンドは excludedCommands でサンドボックス外に逃がす:

{
  "sandbox": {
    "excludedCommands": ["docker *", "watchman *"]
  }
}

エスケープハッチ

サンドボックスで動かないコマンドに遭遇すると、Claude は dangerouslyDisableSandbox パラメータで再実行を試みることがある。これは通常の許可フローを通る (= ユーザの承認が要る)。

完全に無効化したい場合は "allowUnsandboxedCommands": false を設定すると、dangerouslyDisableSandbox 自体を禁止できる ── サンドボックス外実行は excludedCommands の明示許可のみ、という強い縛りになる。

権限システムとの関係

サンドボックスと権限は補完的な二層防御である。

権限 (Permission)サンドボックス (Sandbox)
対象全ツール (Bash・Read・Edit・WebFetch・MCP)Bash とその子プロセスのみ
強制アプリレベルOS レベル
主な役割Claude が使えるツール・パスを制御bash の物理的な可動範囲を制限

両方使うのが定石。例えば:

  • 権限の deny で Read(~/.env) をブロック → Claude のツールは .env を読めない
  • サンドボックスの denyRead で ~/.env を含めると → bash プロセスからも読めない

権限だけだと「Claude が cat .env を bash で実行する」のような迂回経路が残る。サンドボックスでこの迂回も塞ぐ形になる。

結局のところ何が変わるか

サンドボックスを有効化すると:

  • 承認ダイアログが激減する (サンドボックス内のものは自動承認)
  • Claude がより自由に動ける (止まらない)
  • 事故・攻撃の影響範囲が制限される (OS レベルで物理的に)

「auto モードよりは制御を保ちたい、でも default モードの承認攻めは耐えられない」── そういう時の中庸として、サンドボックスは強力な選択肢になる。

次章は、もう一つの「承認疲れ対策」── 分類器が判定する auto モード に入る。サンドボックスとは別のアプローチである。

参考情報