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

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

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(有効=分離あり)です。サンドボックスが動くmacOS・Linux・WSL2のいずれのプラットフォームでも同じように適用されます。

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

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

認証情報の環境変数は守られても、認証情報ファイルの読み取り拒否は外れます。この非対称は事前に押さえておく価値があります。なお、maskエントリがdenyへフォールバックした場合、そのエントリは他のdenyエントリと同様に扱われるため保護は効きません(公式ドキュメント)。

この非対称の理由は、2つの保護が別々の仕組みで動いているからです。sandbox.credentialsはファイルパスと環境変数それぞれにmode(denyまたはmask)を指定する専用ブロックで、v2.1.187以降で使えます。"mode": "deny"のファイルエントリはfilesystem.denyReadと同じ扱いでファイルシステム層の一部として実装されているため、ファイルシステム分離をオフにすると効かなくなります。一方、環境変数のdeny/maskエントリはサンドボックス化コマンドの実行前に環境変数そのものを外す処理で、ファイルシステム層とは無関係に動くため分離をオフにしても外れません。サンドボックスの有無に関わらずAnthropicやクラウドプロバイダーの認証情報をすべてのサブプロセスから取り除きたい場合は、CLAUDE_CODE_SUBPROCESS_ENV_SCRUB環境変数を使います。

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

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

自動承認とファイルシステム分離オフを組み合わせると危険です。サンドボックス化されたコマンドがシェルの起動ファイルや$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で積み上げるより、分離そのものを外してネットワーク許可リストだけで境界を引くほうが構成がシンプルになります。ただしその代償として、上で挙げた保護対象パスと認証情報ファイルの読み取り拒否が同時に外れることを踏まえて選びます。

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

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

よくある質問

ファイルシステム分離をオフにしてもネットワークは制限されますか

されます。sandbox.filesystem.disabledはファイルシステム層だけをスキップする設定で、sandbox.networkの許可ドメイン・拒否ドメインの設定はそのまま効きます。

filesystem.disabledはリポジトリのsettings.jsonに書けば有効になりますか

なりません。プロジェクトの.claude/settings.jsonと.claude/settings.local.jsonからは設定できない仕様です。ユーザー設定・managed設定・--settingsフラグのいずれかに書く必要があります。

管理者がsandbox.filesystemを設定していると開発者は上書きできませんか

managed設定がsandbox.filesystemを何か1つでも設定しているか、"mode": "deny"のcredentials.filesエントリを列挙している場合、filesystem.disabledはmanaged設定からしか変更できなくなります。

ファイルシステム分離をオフにしても認証情報は完全に無防備になりますか

環境変数のdeny/maskエントリとファイルのmaskエントリは効き続けます。効かなくなるのはファイルのdenyエントリ(読み取り拒否)だけです。ただし、maskエントリがdenyへフォールバックしている場合はこの限りではなく、他のdenyエントリと同じく保護されません。

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

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

まとめ

sandbox.filesystem.disabledは「ファイルシステム分離だけを外す」という説明どおりの設定ですが、その範囲には.claude/settings.jsonやhooksディレクトリへの書き込み保護、認証情報ファイルの読み取り拒否まで含まれます。ネットワーク分離は独立して残るので、接続先だけを絞りたい用途には向きますが、自己拡張のリスクを理解した上で信頼できるワークロードに限定するのが公式の立場です。プロジェクト側の設定では変更できないため、有効にする判断はユーザー設定かmanaged設定を扱う側に委ねられます。サンドボックスの設計思想全体はClaude Codeのサンドボックス設計、settings.jsonのsandboxフィールド一覧はClaude Code設定ガイド、DevContainerでの隔離運用はClaude CodeをDevContainerで安全に動かす完全実装で確認できます。