サンドボックスポリシーを設定

エージェントの実行がサンドボックス化されるかどうかは、サーバー側で起動時に決まります（--sandbox）。設定 → サーバー → 診断とプライバシー にある サンドボックスを有効にする トグルと バックエンド ピッカーは、お使いのデバイスに保存される設定です。 サンドボックス化 カードのホスト検出は、サーバーホストが何をラップできるかを報告します。

実行に届く制御は 2 つあり、このガイドではその両方を扱います: エージェントが何をプッシュし、作成し、アクセスできるかを決める 設定 → ワークスペース → エージェントの権限 のアクションのルールと、サーバー自身の --sandbox フラグです。

エージェントの実行を制約するもの

エージェントを制約しているのは 6 つです。1 つ目は OS サンドボックスで、唯一条件付きのものです — 残りの 5 つはどのホストでも保たれます。

境界	動作
OS サンドボックス	macOS では Seatbelt、Linux と WSL2 では bubblewrap。Claude Code CLI、ACP アダプター、ハーネスの `bash` ツールをラップします。Windows、および `bwrap` と `socat` のない Linux では存在しません
エージェント自身のワークツリー	会話ごとにコピーオンライトのチェックアウトを取得します。元のチェックアウトは書き込み拒否パスとして実行に折り込まれ、それを強制するのはサンドボックスです
ブローカー経由の資格情報	資格情報ブローカーは実行ごとの環境を発行し、終了時に取り消します。その GitHub トークンは読み取りはできてもプッシュはできません: プッシュは Control Center を通り、Control Center がまずプッシュのルールに問い合わせます
アクションガードレール	変更を伴うすべてのツールがエフェクトクラスを宣言し、ガードが呼び出しの実行前にそれを解決します。承認者が接続されていない `prompt` は拒否されます
環境のサニタイズ	ACP とハーネスの `bash` ツールはフィルタリングされた環境を受け取ります。`NoSandboxAdapter` 経由の Claude Code はホストの環境を継承します
モードのツールサーフェス	読み取り専用モードはワークツリーを変更するツールを完全に取り除き、それでも成果を届けられるようモード自身の出力動詞を固定します

見た目よりも弱いままの点が 3 つあります:

ツールゲート、完了契約、構造的なモードルールを強制するのは 内蔵ハーネス だけです。 Claude Code アダプターは強制しません。特に Claude Code は --dangerously-skip-permissions 付きで起動されます。非対話の claude -p はそうしなければ自身のプロンプトで永久にブロックしてしまうからです — そのため Claude 自身の read、write、edit 呼び出しは Control Center からも見えず、ゲートもされません。bash コマンドはコマンドラインを読むフックでしか確認されません。サンドボックスがオンの場合、それらを取り囲む境界がサンドボックスです。
ハーネスのインプロセスのファイルツール（read、write、edit、apply patch、search、 find、search_files）はサーバープロセス内で動作するため、サンドボックスプロファイルがそれらを制約することはありません。サンドボックス化されたコマンドランナーを通るのは bash ツールだけです。これらのツールは自身のパス閉じ込めとアクションガードレールによって制限されています。
バックエンドのないホストでは、最初の行がまったく当てはまりません。ACP とハーネスの bash ツールは、環境のサニタイズとコマンドポリシーにフォールバックします。Claude Code は NoSandboxAdapter 経由でホストの環境を継承します。サーバーはその旨を起動ログで通知します。お使いの環境は後述の方法で確認してください。

エージェントがプッシュできるものを決める

git push、GitHub、チケット、ネットワークについて、エージェント単位のトグルはありません。それぞれがアクションのルールです:

ルール	組み込みのデフォルト	対象
リモートへプッシュ	先に確認	アダプターを問わず、GitHub へのすべての `git push`
プルリクエストを作成	先に確認	`gh pr create` とプルリクエストのツール
レビューの公開またはマージ	先に確認	`gh pr merge`、`gh pr review`、`gh pr comment`、`gh pr close`
外部トラッカーへの書き込み	先に確認	Control Center のツールと `gh issue` によるチケットの書き込み
ネットワークにアクセス	許可	サンドボックスにネットワークがあるかどうかと、ハーネスの Web ツール

設定 → ワークスペース → エージェントの権限 を開きます
スコープ（ワークスペース、エージェント、スペース）を選び、ルールの行で許可、先に確認、拒否のいずれかを選びます

main へのプッシュを拒否するルールのような、ブランチに限定したプッシュのルールも適用されます: ガードレールを参照してください。

チェックポイント: エージェントにブランチをプッシュさせます。先に確認 の場合はリポジトリと ref を示す承認の依頼が届き、拒否の場合は git が ! [remote rejected] <ref> (Control Center policy: …) と表示します。

各ルールが実行に届く仕組み:

プッシュ は、実行が何を持っているかによって強制されます。その GitHub トークンは読み取り専用の GitHub App インストールトークンで、コンテンツの読み取りとプルリクエストの操作ができます。その git 設定は GitHub へのすべてのプッシュを cc_server 上のループバックのゲートウェイに送り、ゲートウェイはルールに問い合わせてから、エージェントが決して目にしない書き込みトークンでプッシュを転送します。ゲートウェイが転送するのは、ワークツリー自身のリポジトリか、ワークスペースにリンクされた GitHub リポジトリだけです。これはすべてのアダプターに当てはまります。
シェルからのプルリクエストと Issue は、ハーネスの bash ツールと、フック経由の Claude Code の Bash ツールでコマンドラインから認識されます。コマンドを隠すエージェント（スクリプト、eval、直接の API 呼び出し）はこの確認をすり抜けますが、プッシュのゲートウェイはすり抜けられません。
チケットのキー がサンドボックスに置かれることはありません。エージェントは Control Center の MCP ツールでチケットを書き込み、それらのツールがルールに問い合わせます。
ネットワーク は実行の開始時に一度だけ解決されます。拒否はサンドボックスのネットワークをオフにします。許可と 先に確認 はオンのままにし、先に確認 ではハーネスの web_fetch と web_search ツールが引き続き呼び出しごとに確認します。ネットワークがオンの間、GitHub は常に外向き通信の許可リストに含まれます。

GitHub App が設定されていない場合、実行はフォールバックの個人用アクセストークンを受け取ります。これは読み取り専用に絞り込めません。git push は引き続きゲートウェイとルールを通りますが、トークンを直接使うコードはルールを回避してプッシュできます。ルールを確実に効かせるには GitHub App を設定してください。

実行の GitHub 資格情報は常にブローカーのものだけです — リポジトリ単位の GitHub App インストールトークン、またはフォールバックの PAT であり — 要求したメンバー自身が保存したトークンが使われることは決してありません。オーナーではなく GitHub を接続していないメンバーのために動く実行には、サーバーの PAT は渡されません。

エージェントの実行がサンドボックス化されているか確認する

決めるのは 2 つで、どちらもサーバー側にあります: ホストがバックエンドを提供するかどうかと、 --sandbox がオンかどうかです。この順に確認します。

設定 → サーバー → 診断とプライバシー に移動します
サンドボックス化 カードを読みます。ホスト の項目は cc_server が動作しているマシンであり、今見ているマシンではありません。バックエンド フィールドには ネイティブサンドボックス（macOS では Seatbelt、Linux と WSL2 では bubblewrap）または 分離なし が表示されます。有効の項目はこのデバイスの設定であり、サーバーが実際に使うラップではありません。
サーバーの起動ログを読みます。次の 3 行のうち正確に 1 行が出力されます:
- agent sandbox ON とバックエンドの注記 — 実行はラップされます
- no OS-native agent sandbox on this host と、あればインストールのヒント — 実行はラップされません
- agent sandbox DISABLED by --sandbox off — 意図的なオプトアウト

GET /healthz はサンドボックスの状態を報告しないため、確認するのは起動ログです。

意図的にサンドボックスをオフにするには — プロファイルが誤動作するホストが、このオプションの存在理由です — サーバーを --sandbox off で起動するか、 CC_SERVER_SANDBOX=off を設定します。デフォルトは on で、on は「ホストにバックエンドがあれば使う」という意味であり、「バックエンドを必須にする」という意味では決してありません。

ネイティブサンドボックスのラップが得られない状況が 2 つあります。Windows ではネイティブプローブが常に利用不可を報告し、インストールできるものもありません — エージェントのディスパッチは none を使います。microvm バックエンドは別系統（対話ターミナルとリグ）であり、独自のランタイムを対象にプローブでゲートされます。Linux と WSL2 では bwrap と socat の両方が PATH 上になければなりません。なければプローブは利用不可を報告し、不足しているパッケージを名指しします。

bubblewrap がインストールされた Linux/WSL2 では、標準ポリシーのシークレットファイル glob を、エージェントが後から作成するファイルに対して強制できません。そのようなネイティブ実行は、ルールを黙って無視するのではなく、今では失敗します。したがって、起動プローブが成功しても、Linux のディスパッチが開始できることを保証するものではありません。--sandbox off は意図的な非閉じ込めのオプトアウトであり、セキュリティ境界の代替ではありません。

モードがすでに禁止していることを知る

モードはスペースごとに保存され、モードプリセット レイヤーとしてガードレールリゾルバーに渡されます。4 つのモードのうち 3 つは読み取り専用で、読み取り専用モードは 11 のエフェクトクラスを即座に拒否します:

モード	ワークツリー	プリセットによる拒否
Agent（`chat`）	書き込み可能	なし — 組み込みのデフォルトが適用されます
Plan	読み取り専用	ファイルの削除、ワークツリー外への書き込み、コミット、プッシュ、PR の作成、公開またはマージ、外部トラッカーへの書き込み、パッケージのインストール、プロセスの実行、ワークスペース構造の変更、エンクロージャーの起動または操作
Review	読み取り専用	同じ 11 個です。ユーザーが選択することはできません — コンポーザーが提供するのは Agent、Plan、Orchestrate だけです
Orchestrate	読み取り専用	同じ 11 個です

ネットワークアクセスとシークレットへのアクセスは、読み取り専用モードでも意図的に拒否_されません_。調査こそが読み取り専用モードの目的だからです。

アクションの実行前に承認を必須にする

承認はガードレールの決定であり、サンドボックスの設定ではありません。

設定 → ワークスペース → エージェントの権限 に移動します
ワークスペース、エージェント、スペースのいずれかのスコープで、アクションクラスを 先に確認 に設定します

先に確認 の決定は実行を中断してあなたに尋ねます。承認者が接続されていない場合はフェイルクローズし、アクションは拒否されます。解決順序の全体はガードレールを設定を参照してください。

トラブルシューティング

エージェントがプッシュできず、拒否した覚えもない

git が表示した内容を読んでください。Control Center policy: … は、ルールがプッシュを拒否したか、先に確認 に応答がなかったことを意味します。 … is not linked to this workspace は、プッシュ先がワークツリー自身のリポジトリでもワークスペースにリンクされたリポジトリでもないことを意味します。 Control Center has no GitHub credential that can push … は、そのリポジトリに GitHub App がインストールされておらず、プッシュできるフォールバックの資格情報もなかったことを意味します: そのリポジトリにアプリをインストールするか、GitHub を接続してください。

サンドボックス化カードがネイティブサンドボックスなしと報告する

そのホストのエージェント実行は Seatbelt や bubblewrap でラップされておらず、残りの境界があなたの持っているものです。Linux と WSL2 では、不足している両方のツール — sudo apt-get install bubblewrap socat — をインストールし、サーバーを再起動します。そうすれば起動ログにサンドボックスがオンであると表示されるはずです。Windows にはインストールできるネイティブバックエンドがないため、代わりにガードレールを厳しくします: ガードレールを設定を参照してください。

エージェントがワークツリー外のファイルに到達した

それに到達したのがどのツールかで、これが想定どおりかどうかが決まります。

ハーネスのインプロセスのファイルツール（read、write、edit、apply patch、search、 find、search_files）はサーバープロセス内で動作するため、サンドボックスプロファイルは適用されません — それらの境界は、自身のパス閉じ込めとガードレールです。bash コマンドや Claude Code CLI は、バックエンドが存在する場合はラップ_され_、登録済みのチェックアウトはそのラップ内でどのモードでも書き込み拒否になります。シンボリックリンクを解決した綴りも含まれます（macOS では /tmp や /var/folders を通して到達したパスは /private 配下に解決され、どちらの綴りも拒否されるようになりました）。バックエンドのないホストでは、そのいずれも当てはまりません。どちらの場合でも、ガードレールは ワークツリー外への書き込み を即座に拒否できます。