sandbox.filesystem.disabledはファイルシステム分離だけ外す設定

Claude Codeのサンドボックスは、ファイルシステム分離とネットワーク分離という独立した2つの層でできています。sandbox.filesystem.disabledをtrueにすると、ネットワーク分離は残したままファイルシステム分離だけを外せます。ただし「ファイルシステム分離だけ外す」の中身は見た目より広く、.claude/settings.jsonへの書き込み保護など、普段は当然だと思っている防御もこの1つのフラグで一緒に消えます。サンドボックス全体のオン・オフはsandbox.enabled設定で切り替えます。

sandbox.filesystem.disabledは何を切るのか

デフォルトのサンドボックスは、書き込みを作業ディレクトリとその配下、--add-dirで追加したディレクトリ、ユーザー単位の一時ディレクトリだけに限定します。読み取りはコンピューター全体に及びますが、一部のディレクトリは拒否されます。ここで見落としやすいのは、この既定の読み取り許可には~/.aws/credentialsや~/.ssh/のような認証情報ファイルも含まれる点です。サンドボックスを有効にしただけでは認証情報の読み取りはブロックされません。遮断するにはsandbox.credentialsで個別に指定する必要があります。

sandbox.filesystem.disabledはこのファイルシステム層を丸ごとスキップします。ネットワーク層は別の仕組みなので、ドメイン許可リストはそのまま効き続けます。

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "disabled": true
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

この設定を入れると、サンドボックス化されたコマンドはホストのファイルシステムに無制限の読み書きアクセスを得ます。ネットワークの出口だけ絞りたいときの構成です。要求バージョンは2.1.216以降で、既定値はfalse(有効=分離あり)です。

無効化しても保護され続けるもの・されなくなるもの

filesystem.disabledが外すのはファイルシステム層の保護だけです。他の層が担う保護は無効化後も効き続けます。

sandbox.credentialsはファイルパスと環境変数それぞれにmode(denyまたはmask)を指定する専用ブロックで、v2.1.187以降で使えます。"mode": "deny"のファイルエントリはfilesystem.denyReadと同じ扱いでファイルシステム層の一部として実装されています。一方、環境変数のdenyエントリは実行前に変数を外し、maskエントリは変数をプレースホルダーに置き換えます。どちらもファイルシステム層とは無関係に動きます。maskエントリは環境変数がv2.1.199以降、ファイルがv2.1.221以降で使え、ユーザー設定・managed設定・--settingsだけで有効です。macOSではファイルのmaskエントリが分離オンのときdenyとして適用され、分離をオフにしても読み取りブロックは続きます。サンドボックスの有無に関わらずAnthropicやクラウドプロバイダーの認証情報をすべてのサブプロセスから取り除きたい場合は、CLAUDE_CODE_SUBPROCESS_ENV_SCRUB環境変数を使います。

より重い影響を受けるのが「保護対象パス」です。ファイルシステム分離が有効なときは、書き込み可能な範囲の中でも、Claude Codeが設定やコードを読み込むファイルへの書き込みが固定で拒否されます。対象は4グループに分かれます。

このリストはallowWriteエントリやEditの許可ルールでそのパスを指定しても解除されません。外す手段はfilesystem.disabledだけで、しかもこれを設定するとリストの4グループすべてが同時に保護を失います。configという名前のファイルは、HEADが無くても拒否されます。LinuxとWSL2では、コマンド実行中に現れたトップレベルのHEADファイルやobjects・refsディレクトリを、サンドボックスが削除します。セッション中に保護対象の設定ファイルへのパスにシンボリックリンクが現れた場合は、リンク先のファイルへの書き込みも次のコマンドから拒否対象になります。

自動承認とファイルシステム分離オフを組み合わせると危険です。サンドボックス化されたコマンドがシェルの起動ファイルや$PATH上の実行可能ファイル、~/.claude/settings.jsonを書き換えられます。すると次回実行時に、自分のアクセス範囲を広げる経路が生まれます。公式ドキュメントはこの構成を「自己拡張しないと信頼できるワークロードにだけ使う」よう明確に警告しています。

プロジェクト設定では有効化できない

filesystem.disabledを書けるスコープは限定されています。ユーザー設定・managed設定・--settingsのCLIフラグからは設定できますが、プロジェクトの.claude/settings.jsonと.claude/settings.local.jsonからは設定できません。チェックアウトしたプロジェクト側の設定ファイルだけでファイルシステム分離を切ることはできない設計です。

--setting-sourcesやAgent SDKのsettingSourcesでプロジェクト設定やローカル設定を除外した場合、Claude Codeはサンドボックス構成を組み立てる際にそのスコープのsandbox.filesystemエントリ・Edit権限ルール・Read拒否ルールをまとめて無視します(v2.1.246以降)。sandbox.credentialsにも似た除外挙動があります。プロジェクト設定やローカル設定を除外すると、そのスコープのcredentialsエントリはすべて適用されなくなります。一方、ユーザー設定を除外した場合はdenyエントリとファイルのmaskエントリは残り、環境変数のmaskエントリだけが外れます。設定ソースを絞り込むときは、filesystem.disabledだけでなくこうした周辺ルールがどのスコープから読まれているかもあわせて確認します。

managed設定がsandbox.filesystemを何か1つでも設定している場合、あるいは"mode": "deny"のsandbox.credentials.filesエントリを1つでも列挙している場合は、filesystem.disabledはmanaged設定からしか変更できなくなります。管理者がデプロイしたファイルシステム制限を、開発者側の設定で緩めさせない仕組みです。さらにCLAUDE_CODE_SUBPROCESS_ENV_SCRUB環境変数が設定されているセッションでは、filesystem.disabledはどのスコープの値も無視され、ファイルシステム分離は常にオンのままになります。

$TMPDIRの挙動も切り替わる

ファイルシステム分離が有効なとき、サンドボックス化されたコマンドの$TMPDIRはユーザー単位の一時ディレクトリを指します。分離をオフにすると、あらゆる一時ディレクトリが書き込み可能になるため、Claude Codeはこのリダイレクトをやめ、サンドボックス化されたコマンドはシェル本来の$TMPDIRを継承します。Linuxでは親シェルの$TMPDIRが未設定のことが多く、その場合は空文字列に展開されます。Claude CodeはこのケースをBashツールのガイダンスとしてClaudeに伝え、$TMPDIRに頼らずmktemp -dでスクラッチディレクトリを作るよう促します。

autoAllowBashIfSandboxedは分離をオフにしても既定でtrueのままです。ファイルシステム分離を切った後もサンドボックス化されたコマンドはプロンプトなしで実行され続けるので、確認を挟みたい場合はこの設定を明示的にfalseにします。

使いどころ: 書き込みは信頼するがネットワークだけ絞りたいとき

kubectlやterraformのようにファイルシステムへ広く書き込むツールを、外部への接続経路だけ管理したい場面がこの設定の主な使いどころです。ファイルシステムの許可パスを1つずつsandbox.filesystem.allowWriteで積み上げるより、分離そのものを外してネットワーク許可リストだけで境界を引くほうが構成がシンプルになります。ただしその代償として、上で挙げた保護対象パスと認証情報ファイルの読み取り拒否が同時に外れることを踏まえて選びます。/etc/nginxのような作業ディレクトリ外のパスへ設定ファイルを書く場面も同じ判断が必要になり、具体的な進め方はClaude Codeでnginx設定ファイルを作成する手順で扱っています。

ここで残るネットワーク分離が具体的に何をするかも押さえておく価値があります。サンドボックスはドメインを既定で1つも許可しません。コマンドが新しいドメインに接続しようとするたびに、Claude Codeは承認を求めるか、auto modeでは分類器に判断を委ねます。allowedDomainsにあらかじめ列挙しておけばプロンプトなしで通り、strictAllowlistをtrueにすると許可リスト外のホストはプロンプトの代わりに問答無用で拒否されます。この2つの設定はファイルシステム層とは独立しているため、filesystem.disabledの影響を受けません。

ただし、この構成には公式ドキュメントが明記する限定があります。ファイルシステム分離が無い状態では、侵害されたコマンドがシステム資源にバックドアを仕込み、ネットワークアクセスそのものを得てしまう可能性があります。つまり「ネットワーク分離は独立して残る」は平常時の話で、ファイルシステム側が突破された後の保証ではありません。allowManagedDomainsOnlyを有効にしてもこのリスクは狭まるだけで消えません。このロックが効くのはサンドボックス内のコマンドに対してだけです。

有効にする前に手元で確かめる2点

設定ファイルに1行足すだけで切り替わるので、書く前の確認が実質的な安全装置になります。出力例はv2.1.287のものです。

--settingsに渡す形は、claude --helpの出力で次のように説明されています。--setting-sourcesの選択肢も、同じ出力にuser・project・localの3つとして載っています。

claude --version
claude --help | grep -A3 -E "^\s+--setting"

2.1.287 (Claude Code)
  --setting-sources <sources>           Comma-separated list of setting sources
                                        to load (user, project, local).
  --settings <file-or-json>             Path to a settings JSON file or a JSON
                                        string to load additional settings from

分離がオンのとき、git mergeやgit checkoutがunable to unlink oldで失敗することがあります。保護対象パス、denyWriteのエントリ、書き込み許可の外にあるファイルのいずれかを置き換えようとした場合です。LinuxとWSL2では、エラーの末尾がRead-only file systemになります。この摩擦を避けるためだけに分離を外すと、上の一覧がまとめて消えます。対処は下のFAQにあります。

よくある質問

git worktreeで作業している場合、書き込み許可の扱いは変わりますか

分離が有効なときは、worktreeのメインリポジトリが共有する.gitディレクトリへの書き込みがgit commitのために特別に許可され、その中でもhooks・configだけは引き続き拒否されます。分離そのものをオフにした場合はホストのファイルシステム全体が書き込み可能になるため、この個別扱いは意味を持たなくなります。

unable to unlink oldで失敗したときは

Claudeがサンドボックス外での再実行を提案することがあるので、承認するか、別のターミナルで自分でgitコマンドを実行します。allowUnsandboxedCommandsをfalseにしている場合は提案が出ないため、自分で実行します。

まとめ

一時的に外すだけなら--settingsで1セッションに留められ、常時外す場合は先に認証情報をmaskや環境変数のエントリへ寄せておく選択肢があります。

サンドボックス全体の設計はClaude Codeのサンドボックス設計、sandboxフィールドの一覧はClaude Code設定ガイド、コンテナで隔離する運用はClaude CodeをDevContainerで安全に動かす完全実装にあります。