各レイヤーが守る範囲と守れない範囲
レイヤーごとに判断の根拠が違うため、どのレイヤーにも、ほかのレイヤーが拾う見落としがあります。OS サンドボックスの仕組み
サンドボックスの実装はプラットフォームによって異なりますが、多くは同じ OS のプリミティブ（macOS の Seatbelt、Linux の bubblewrap）に行き着き、既定の方針もほぼ共通です。読み取りは広く許可し、書き込みは作業ディレクトリと一時ディレクトリに限定し、ネットワークアクセスは制限するか既定で無効にします。また、どの実装も 2 つの制御を分けています。サンドボックスは、何に触れられるかを定める技術的な境界です。承認ポリシーは、エージェントが操作前にユーザーへ確認を求めるべき場面を定めます。保護のレイヤーが異なる
コーディングエージェントにとってのサンドボックスの限界
サンドボックスが制限するのは書き込める場所であって、その範囲内でプロセスが何をするかまでは判断しません。Claude Code のサンドボックスドキュメントは、既定で書き込みを作業ディレクトリに限定します。そのため、プロジェクトに対するgit reset --hard と rm -rf . は許可されたパスへの操作となり、OS からは正当な書き込みに見えます。git push --force はネットワーク越しにリモートを書き換えるだけで、ローカルには何も書き込みません。そのため、ファイルシステムの書き込み範囲ではそもそも捉えられません。次のコマンドはいずれもサンドボックスでは許可されます。カレントディレクトリ内に書き込むか、サンドボックスが許可したファイルを読み取るか、許可されたリモートに接続するだけだからです。
これらのコマンドが自動的に実行されるか確認を求められるかは、エージェントのサンドボックスモードと承認ポリシーによって決まります。
git push --force のようなネットワークを使うコマンドは、許可ドメインの設定にも左右されます。サンドボックスから見れば
git reset --hard は安全な操作です。カレントディレクトリ内のファイルしか変更しないからです。しかし実際には、その時点でコーディングエージェントが未コミットの作業をすべて破棄してしまっています。~/.aws/credentials と ~/.ssh/ を今も読み取りを許可するファイルとして名指ししています。CC Safety Net は、設定なしでこれらのパスへのコンテンツアクセスをブロックします。
同じ違いは、コマンドプロキシにも当てはまります。ユーザーの代わりにコマンドを実行するツールは、どちらのレイヤーから見ても 1 つの不透明な実行ファイルにすぎません。しかし cc-safety-net rule wrapper add <command> で宣言しておけば、CC Safety Net はそのプロキシを透過して子コマンドを見て、同じルールを適用します。サンドボックスは子コマンドをまったく検査せず、プロセスツリー全体が何に触れられるかを制限するだけです。
サンドボックスのほうが適している場面
主な懸念が次のような場合は、サンドボックスが適切な手段です。- プロンプトインジェクション攻撃：外向きの通信先ドメインを制限し、情報流出のリスクを下げる
- 悪意のある依存関係：信頼できないパッケージによるファイルシステムへの書き込みとネットワークアクセスを制限する
- 信頼できないコードの実行：OS レベルの封じ込めは、コマンド文字列の解析より本質的に強い
- ネットワークの制御：CC Safety Net にはネットワークに対する保護がまったくない
CC Safety Net が対処できない範囲
CC Safety Net が行うのは、対応するツール呼び出しの解釈であって、プロセスの封じ込めではありません。次に挙げる限界は、意味解析ではなく封じ込めによってしか埋められません。- ネットワーク経由の情報流出。 実行時の評価ではネットワーク通信を一切行わず、処理のどの段階でも外向きの通信を検査しません。通信先ドメインの許可リストは、サンドボックスが担う領域です。
- 認識対象外のファイルの読み取り。 機密パスの保護が対象とするのは、
.envとその派生形、SSH 鍵、クラウドの資格情報ストア、コーディング CLI の資格情報ファイル、設定した deny path という限定されたパターン群で、対応するコマンド、パス、検索、patch の各形式にわたって適用されます。全一覧はシークレット保護リファレンスにあります。汎用の読み取り境界ではないため、認識対象外のファイルに置かれた資格情報は保護されません。サンドボックスは、どのファイルが重要かを知らないまますべての読み取りを制限します。 - バイナリの内部に隠された動作。
some-tool --task destructive-cleanupは、コマンド文字列の上では無害に見えます。また、見える形で子コマンドを実行せずに書き換えてしまうプロキシは、transparent wrapper として設定しても透過できません。 - ファイルシステムに対する完全な強制。 拒否はそのツール呼び出しを止めるだけで、権限そのものを強制するわけではありません。ベストエフォートのインターセプトでは足りず完全な保護が必要な場合は、信頼できる書き込みブローカー、OS のパーミッション、サンドボックスのいずれかを使ってください。
許可プロンプトと自動承認の分類器
ユーザーにいちばん近いのは、確認を求めるレイヤーです。Claude Code の許可モードのドキュメントはこう説明しています。Manual モードでは、Claude Code は「stops and asks you before most actions that edit files, run shell commands, or reach the network」。auto モードでは「a second model, the classifier, reviews actions instead of you」。分類器が既定でブロックする操作の一覧には、「git reset --hard, git checkout -- ., git restore ., git clean -fd, git stash drop, or git stash clear, which the classifier presumes would discard uncommitted changes」が含まれます。
この審査は判断であり、切ることもできます。Anthropic は、Claude Code の auto-mode 分類器について、実際の行き過ぎた操作に対する偽陰性率 17% を公表し、「not a drop-in replacement for careful human review」だとしています。同じ許可モードのドキュメントは、bypassPermissions で確認なしに実行される範囲を「Everything」と記載し、このモードを「Isolated containers and VMs only」に勧めています。
決定的なチェックは、モードを切り替えても残ります。同じページには「Deny rules block in every mode, including bypassPermissions」とあります。CC Safety Net の拒否も同じように振る舞います。Claude Code 2.1.251 に対して検証したところ、PreToolUse の deny は default、auto、bypassPermissions のいずれのモードでも発火しました（プロジェクトリポジトリの tests/e2e-live/protection.test.ts）。これはバージョンごとの結果であって恒久的な保証ではないため、このスイートはリリースとホストの更新のたびに再実行します。deny ルールが守れるのは、あらかじめ書き出せた操作を、CLI ごとの書式で指定した分だけです。CC Safety Net は 13 の CLI にまたがって 1 つのポリシーを適用し、1 つの監査証跡を残します。
コンテナ・VM・チェックポイント
使い捨てのマシンは、本物の封じ込めです。プロンプトを切ったときに、許可モードのドキュメントが指し示す先でもあります。bypassPermissions は「Isolated containers and VMs only」向けだとされています。ただし、マシンが使い捨てでも、その中の作業は変わりません。クラウドセッションは実在のブランチでリポジトリを clone し、commit し、実在のリモートに push します。未コミットの作業に対する git reset --hard は、ローカルで失うのと同じ作業を失わせますし、git push --force はチームメイトが pull するブランチに着地します。同じセッションのクレデンシャル側はクラウド環境で扱っています。作業ツリーをマウントするローカルのコンテナも同じです。そのマウントは書き込み可能で、未コミットの作業はそこにあります。
チェックポイントは、この隙間を狭めますが、塞ぎはしません。Claude Code のチェックポイントのドキュメントは、チェックポイントが「automatically captures the state of your code before each user prompt」と述べたうえで、限界をこう記しています。「Checkpointing does not track files modified by bash commands.」。そこで例に挙がっているのは rm file.txt、mv old.txt new.txt、cp source.txt dest.txt です。これらの変更について、同じページは「These file modifications cannot be undone through rewind. Only direct file edits made through Claude’s file editing tools are tracked.」としています。破壊的な git コマンドは bash コマンドとして実行されるため、それが捨てた作業は rewind で戻せる範囲の外にあります。同じページは、チェックポイントを「quick, session-level recovery」と位置づけ、「continue using version control, such as Git, for commits, branches, and long-term history」と述べています。
サンドボックスと CC Safety Net を併用する
サンドボックスは、エージェントが OS レベルでできることを制限することで、未知の脅威に対処します。CC Safety Net は、既知の破壊的パターンを実行前にインターセプトします。併用すれば、片方だけでは残ってしまう隙間を互いに埋められます。 ほかのレイヤーも、同じように積み重なります。分類器は、静的なチェックでは決められない場面で意図を判断します。使い捨てのマシンとチェックポイントは、そこをすり抜けたものの一部を、影響範囲の限定と rewind で和らげます。どちらも、決定的なチェックが受け持つ場面では効きません。 サンドボックスと許可リスト自体も破られることがあります。CVE-2026-25725 はsettings.json を介して Claude Code の bubblewrap サンドボックスを脱出し、CVE-2026-22708 は Cursor のコマンド許可リストを回避しました。手元にあるレイヤーは、すべて動かしてください。