Claude Code のサンドボックスを読む——シェルコマンドに引く「OSの境界線」と、その外側

結論：サンドボックスは「シェルコマンドの境界」で、すべての操作を囲うものではない

先に要点をまとめます。

• Claude Code の Bash サンドボックスは、AIが実行するシェルコマンドと、そこから起動されるプロセスに対して、触れてよいファイルとネットワーク先をOSの機能で制限します。
• 初期状態ではオフです。/sandbox コマンドを使うか、設定ファイルで sandbox.enabled を true にすると有効になります。
• 公式ドキュメントには「サンドボックスの対象はシェルコマンドだけで、Claude のファイル操作ツール、MCPサーバー、フックはその外側で動く」と書かれています。
• 許可リストにない接続先へのつなぎ方は、権限モードによって異なります。確認画面が出るモード、確認なしで通るモード、拒否されるモードがあります。

医療・ヘルスケアの開発現場では「AIに任せても大丈夫な範囲」を説明できることが欠かせません。以下、公式ドキュメントの記載に沿って、境界の内側と外側を順に見ていきます。なお、この記事は以前のコラム「Claude Code の権限ルール（allow・ask・deny）」の続きにあたります。

ファイル：書き込みは狭く、読み取りは広い

サンドボックス内のコマンドが書き込めるのは、初期状態では次の場所です。

• 現在の作業ディレクトリ
• ユーザーごとの一時ディレクトリ
• --add-dir、/add-dir、permissions.additionalDirectories で追加したディレクトリ

ほかの場所に書き込ませたいときは、sandbox.filesystem.allowWrite で明示的に指定します。

一方で、読み取りは初期状態でコンピューター全体が対象です（一部の拒否されたディレクトリを除く）。公式ドキュメントも、この初期設定のままでは認証情報のファイルが読めてしまうので、読ませたくない認証情報は別途保護するよう注意しています。データファイルや接続情報を同じ端末に置いている場合は、「書き込みが制限されていれば安心」とは言えません。

書き込みできる場所の中でも守られるファイル

書き込みが許された場所の中にも、Claude Code が設定やコードを読み込むファイルについては、書き込みを拒否する決まりがあります。ただし、どこで守られるかは項目ごとに違います。

• 作業ディレクトリとその上位のディレクトリ：.claude の設定ファイル、.claude/skills・.claude/agents・.claude/commands・.claude/hooks の各ディレクトリ、.mcp.json など
• 作業ディレクトリの中だけ：.bashrc や .zshrc などのシェル起動ファイル、.gitconfig、.vscode と .idea のディレクトリ、.git 内の hooks と config
• ~/.claude（または CLAUDE_CONFIG_DIR で指定した場所）：その中身の大部分と、~/.claude.json、認証情報の保存ファイル .credentials.json

たとえば .bashrc の保護は「作業ディレクトリの中」での決まりとして書かれています。追加したディレクトリにある同じ名前のファイルまで一律に守られるとは書かれていないので、追加ディレクトリの範囲は必要最小限にしておくのが無難です。また、allowWrite や Edit の許可ルールでこれらのファイルを範囲に含めても、保護は外れないとされています。

ネットワーク：許可リストは空から始まり、外れた接続の扱いはモードで変わる

サンドボックス内のコマンドは、ネットワークに直接つながりません。接続は端末内のプロキシを通り、そこでホスト名が許可リスト・拒否リストと照合されます。許可リスト（network.allowedDomains）は空の状態から始まります。

許可リストにないホストへの接続がどう扱われるかは、公式ドキュメントの表で次のように示されています。

つまり、確認画面が出るかどうかはモード次第です。bypassPermissions では確認なしで通る点に注意が必要です。どのモードでも外に出したくない接続先は、deniedDomains に入れておけば、すべてのモードで拒否されます。また、strictAllowlist か allowManagedDomainsOnly を有効にすると、許可リストにない接続はどのモードでもプロキシが拒否します。

「サンドボックスの外で再実行」という抜け道と、それを止める設定

サンドボックスと相性の悪いツールのように、サンドボックス内では失敗するコマンドもあります。そのような場合、Claude は失敗の内容を見て、dangerouslyDisableSandbox という指定を付けてサンドボックスの外で再実行することがあります。この再実行の扱いもモードによって異なります。

• bypassPermissions モード：確認なしで実行
• Manual モード・acceptEdits モード：「Bash command (unsandboxed)」という確認画面が出る
• Auto モード：別の分類器がコマンドを評価
• dontAsk モード：拒否

注意したいのは、Bash(curl *) のような許可ルールがコマンドに合致すると、その再実行も承認されてしまい、確認なしでサンドボックスの外で実行されることです。

これに対しては、2つの手当てが用意されています。

• Bash(dangerouslyDisableSandbox:true) を ask ルール（確認を求めるルール）として追加すると、再実行のたびに確認画面が出ます。公式ドキュメントでは、この確認は Auto モードや bypassPermissions モードでも出て、合致する許可ルールより優先されるとされています。
• "allowUnsandboxedCommands": false を設定すると、Claude Code は dangerouslyDisableSandbox の指定を無視するため、再実行の抜け道そのものがなくなります。

境界の外にあるものと、起動しなかったときの動き

最後に、サンドボックスでは囲えないものを整理します。

• シェル以外の操作：ファイル操作ツール、MCPサーバー、フックはサンドボックスの外で動きます。これらは権限ルールなど別の仕組みで管理します。
• 対応していない環境：サンドボックスが動くのは macOS（Seatbelt を使用）、Linux と WSL2（bubblewrap を使用）です。Windows 上で直接動かしている場合、コマンドはサンドボックスなしで実行されます。
• 起動に失敗したとき：初期設定では、サンドボックスを起動できないとコマンドはサンドボックスなしで実行されます。sandbox.failIfUnavailable を true にすると、その場合は起動時に終了します。

医療情報を扱うチームなら、「有効にしたつもりで、実は効いていなかった」状態は避けたいところです。/sandbox の Config タブで、実際に適用されている設定を確認できます。

それでも、サンドボックスは「AIに渡してはいけない情報を渡しても大丈夫にする仕組み」ではありません。患者情報や個人を特定できる情報は外部のAIに入力しない。開発には架空のデータを使う。そのうえで、サンドボックス・権限ルール・フックを組み合わせ、それぞれが受け持つ範囲を書き出しておく。この順番で考えるのが現実的です。端末の外にデータを出さない構成を検討する場合は、オンプレミスLLMの解説も参考になります。

当社では、医療・ヘルスケアの業務にAIを取り入れる際の設計や、開発環境の安全な使い方の整理をお手伝いしています。お気軽にご相談ください。