2026年9月24日時点の結論：GitHub は 2026年9月23日、GitHub Copilot アプリにローカルサンドボックス（public preview）を追加しました。エージェントが実行するツールを OS のサンドボックスの中で動かし、ファイル・ネットワーク・認証情報の 3 つへのアクセスを制限します。既定はオフで、プロジェクト単位に「Sandbox new sessions」をオンにすると新しいローカルセッションから効きます。実行中のセッションは /sandbox on でそのセッションだけ有効化できます。
- 効く範囲：ローカルリポジトリと working tree のセッションだけ。クラウドサンドボックスのセッションとリモートホスト上のセッションには効きません。
- 止まり方：OS が要求したポリシーを強制できない時は、サンドボックスなしで走らせるのではなくエラーで止まります。
- Copilot CLI とは別管理：CLI 側は
/sandboxの 4 タブ（General／Auth／Filesystem／Network）で設定します。アプリの設定は CLI に引き継がれません。
Copilot の CLI にはすでにローカルサンドボックスがありましたが、GUI のアプリ側は「working tree で並行セッションのファイルを分ける」だけで、コマンドがマシンのどこにアクセスできるかは制限していませんでした。今回の追加で、アプリのエージェントにも OS レベルの境界が入ります。この記事では、公式 changelog と GitHub Docs に書かれている範囲で、設定項目・効き方・止まり方と、Claude Code や Codex CLI のサンドボックスとの位置関係を整理します。筆者はまだ実機で試していないため、手順は「公式の説明では」の範囲です。
Copilot アプリのローカルサンドボックスとは｜制限する対象は 3 つ
GitHub Docs の定義は「エージェントがあなたの代わりに起動するツールを、OS のサンドボックスの中で走らせる。意図しないコマンドの影響を、ファイル・ネットワークリソース・認証情報へのアクセスを制限することで小さくする」というものです。制限の対象は次の 3 分類で、プロジェクトごとに設定します。
| 分類 | 設定項目（公式の名前） | 既定 |
|---|---|---|
| Filesystem（ファイル） | Additional read/write／Additional read-only／Denied の 3 つのフォルダ一覧 | ワークスペースと現在の作業ディレクトリに読み書き可 |
| Network（ネットワーク） | Outbound internet（外向きインターネット）／Local network（ループバックとローカルネットワーク） | どちらも許可 |
| Credentials（認証情報） | Git credentials（HTTPS の認証つき Git 操作）／GitHub CLI credentials（gh の認証） | どちらも利用可 |
公式は「ほとんどのプロジェクトは既定のポリシーから始めてよい」と書いています。既定のままでも、依存関係のインストール、ローカル開発サーバーへの接続、ブランチの push、PR の作成といった日常の作業は通ります。制限を足すのは、プロジェクトの隣に機密フォルダがある、ネットワークが要らない、自分の認証情報を使わせたくない、という時です。
有効化の手順｜既定はオフ、プロジェクトごとにオンにする
ローカルサンドボックスは既定でオフです。公式の手順は 3 段です。
- アプリの設定を開く。
- 設定したいプロジェクトを選ぶ。
- 「Sandbox」の下にある Sandbox new sessions をオンにする。
この設定は新しいセッションに適用され、すでに動いているセッションは変わりません。実行中のセッションで有効にしたい時は、そのセッションに次を入力します。
/sandbox on逆に切る時は /sandbox off です。セッション中に入力した場合は「そのセッションだけの上書き」として即時に効き、他のセッションのプロジェクト既定は変わりません。セッションが始まる前に入力した場合は、新しいセッションが継承するプロジェクト既定を変える、という挙動の違いがあります。
ファイル・ネットワーク・認証情報の設定を変えた時は、新しいセッションか、既存セッションの再起動で反映されます。履歴を保ったまま再起動するコマンドも用意されています。
/restart-sessionポリシーの中身｜ファイル・ネットワーク・認証情報の 3 つを別々に決める
ファイル：追加の読み書き・読み取り専用・拒否
既定では、サンドボックス内のセッションはワークスペースと現在の作業ディレクトリに読み書きできます。プロジェクト設定の Sandbox 節で、次の 3 つの一覧にフォルダを足します。
- Additional read/write：エージェントのツールが読んで書き換えてよいフォルダ
- Additional read-only：読めるが書き換えられないフォルダ
- Denied：アクセスできないフォルダ
公式が明記している優先順位は「より具体的な Denied は、親フォルダに読み書きの許可があっても拒否のまま」です。たとえばホームに読み取りを許しても、その下の秘密鍵のフォルダを Denied に入れておけば拒否されます。
ネットワーク：外向きとローカルを分けて切れる
既定ではインターネットにもローカルネットワークにもつながります。切れるのは 2 つで、Outbound internet（GitHub やパッケージレジストリなど）と Local network（ループバックとローカルネットワーク、ローカル開発サーバーへの接続を含む）です。ネットワークを絞るとパッケージのインストール・API 呼び出し・プレビューサーバーが影響を受けます。
Linux には注意書きがあります。「サンドボックスは、シェルコマンドやローカルの MCP・LSP サーバーのような子プロセスのローカルネットワークアクセスを独立して制御できない。設定はプロセス内の操作（Web リクエストやリモート MCP 接続）には効く」と書かれています。Linux でローカルネットワークだけを閉じたつもりでも、子プロセスには届かない場合があるということです。
認証情報：Git と gh を別々に切れる
既定では、認証つきの Git 操作と GitHub CLI の操作がサンドボックス内で使えます。Git credentials（認証つき HTTPS Git 操作）と GitHub CLI credentials（GitHub CLI の認証）を個別にオフにできます。オフにすると、サンドボックス内からのブランチの push や PR の作成が止まります。
強制できない時はエラーで止まる｜サンドボックスなしでは走らない
この機能でいちばん覚えておきたい仕様です。公式は「アプリは、OS が強制できるかを確認する前にサンドボックス設定を受け付ける。対応の確認は最初のサンドボックス付きシェルが起動する時に行う。ホストが要求ポリシーを強制できなければ、シェルは unsupported-platform か unsupported-policy のメッセージで失敗し、サンドボックスなしでは実行しない」と書いています。
- Windows では、Denied のパスを設定に保存できても、有効な Windows のサンドボックス機能がその拒否を保証できない場合、コマンドは unsupported-policy で失敗します。拒否パスにアクセスできる状態で走ることも、サンドボックスなしで走ることもありません。
- アプリに「Sandbox unavailable」と出た時は、示された問題を直してから「Retry sandbox」を押します。
「設定したのに動かない」より「設定したのに素通りした」の方が危ないので、失敗側に倒す設計です。対応 OS のバージョン一覧は GitHub Docs の「Windows OS support for Copilot sandboxing」に分かれています（参照日 2026年9月24日時点で、CLI 側のドキュメントには「Windows のローカルサンドボックスは Windows Insiders ビルドが必要」と書かれています）。
「Run outside the sandbox?」の出方と、企業管理設定の優先
ツールがポリシーで許されていないアクセスを必要とすると、アプリは「Run outside the sandbox?」と聞いてきます。選べるのは 3 つです。
- 操作をキャンセルする。
- その操作を 1 回だけサンドボックスの外で実行する。
- 現在のセッションの残りはサンドボックスを無効にして実行する。
3 を選ぶと「Sandbox off for this session」と表示され、「Re-enable sandbox」で戻せます。この一時的な無効化はプロジェクト既定もセッションの上書きも変えず、セッションの再起動か再接続で終わります。
もう 1 つ、企業管理設定（enterprise managed settings）があると、実際に効くポリシーはプロジェクト設定より厳しくなることがあります。企業のオーナーは「サンドボックスの外でツールを実行する」こと自体を禁止できます。個人の設定はあくまで「アプリが要求するポリシー」で、有効なポリシーは企業側の設定と合成された結果です。
Copilot CLI・クラウド・リモートとの関係｜アプリの設定は CLI に引き継がれない
同じ「Copilot のローカルサンドボックス」でも、アプリと CLI は設定が別です。公式は「GitHub Copilot app と Copilot CLI のサンドボックス設定は別々に構成する」と明記しています。
| 面 | ローカルサンドボックスの扱い | 設定の場所 |
|---|---|---|
| Copilot アプリ（ローカルリポジトリ／working tree） | 対象。既定オフ・プロジェクト単位 | アプリ設定の Sandbox 節、セッション内 /sandbox on|off |
| Copilot CLI | 対象。別管理 | /sandbox の 4 タブ（General／Auth／Filesystem／Network）。/sandbox enable／/sandbox disable でも切替 |
| クラウドサンドボックスのセッション | 対象外（ローカルサンドボックスは効かない） | クラウド側の環境設定 |
| リモートホスト上のセッション | 対象外 | そのホスト側 |
CLI 側のドキュメントには、アプリ版にない項目もあります。「Allow sandbox bypass（モデルが個別コマンドをサンドボックス外で実行するよう求められる・既定オン）」「Sandbox MCP servers（MCP サーバーをサンドボックス内で動かす・既定オン）」「Sandbox LSP servers（言語サーバーをサンドボックス内で・既定オン）」の 3 つで、企業管理で固定された設定は「(managed)」と表示されて変更できません。CLI ではファイルの読み書きツールが「サンドボックスの子プロセスではなく CLI 自身の中で動くため、同じポリシーを確認するがソフトウェア側の保護であって OS が強制するものではない」という注意もあり、何が OS に強制され、何が CLI の自主チェックなのかが文書化されています。
Claude Code・Codex CLI との比較｜3 つとも「OS が強制・失敗側に倒す」
主要な CLI エージェントは、2026年9月時点でいずれも OS レベルのサンドボックスを持っています。公式ドキュメントに書かれている範囲で並べます。
| 観点 | GitHub Copilot アプリ | Claude Code | Codex CLI |
|---|---|---|---|
| 既定 | オフ（プロジェクト単位でオン） | /sandbox のパネルで有効化。モードは auto-allow か regular permissions |
OS 強制のサンドボックスが既定。ネットワークは既定オフ、書き込みは作業中のワークスペースに限定 |
| 制限の軸 | ファイル（追加 RW／RO／Denied）・ネットワーク（外向き／ローカル）・認証情報（Git／gh） | ファイルとネットワーク（許可ドメイン）。作業ディレクトリと一時ディレクトリに書き込み可 | sandbox mode（read-only／workspace-write／danger-full-access）と approval policy の 2 層 |
| 外で走らせたい時 | 「Run outside the sandbox?」で 1 回だけ／セッションの残り。企業設定で禁止可 | 違反を検知すると dangerouslyDisableSandbox で再試行する逃げ道があり、allowUnsandboxedCommands: false で塞げる（Strict sandbox mode） |
approval policy が「サンドボックスを出る・ネットワークを使う・信頼外のコマンド」で確認を求める |
| 対応 OS | Windows は対応バージョンに条件（強制できなければ失敗） | macOS（Seatbelt）・Linux・WSL2。ネイティブ Windows は非対応 | OS ごとの仕組みで強制（公式ページ参照） |
3 つの共通点は「制限を強制できない時にサンドボックスなしで走らせない」ことと「外に出る操作は必ず人の確認か管理者設定を通す」ことです。違いは既定の向きで、Codex CLI は最初からネットワークを閉じ、Copilot アプリは最初は開いていて必要に応じて閉じます。Claude Code は「サンドボックス内なら自動承認」を選べるのが特徴です。Claude Code の設定は既刊の Claude Code サンドボックス mask モード解説、隔離環境の設計は AI エージェント サンドボックス設計 と E2B・Daytona・Modal 比較 で整理しています。
エージェント開発での使いどころ｜「隣のフォルダ」と「認証情報」から絞る
公式が制限を足す条件として挙げているのは、①プロジェクトの隣に機密フォルダがある、②ネットワークが要らない、③自分の認証情報を使わせたくない、の 3 つです。開発の現場に当てはめると次のような使い方になります。
- モノレポの一部だけ触らせる：ワークスペースは既定で読み書き可なので、触ってほしくない隣のパッケージや
.envのあるフォルダを Denied に入れます。より具体的な Denied が勝つので、親に読み取りを許していても安全です。 - オフラインで回すテスト：依存の解決が終わった後の単体テストは Outbound internet を切って走らせると、テスト中に外へ出る処理が混じっても止まります。プレビューサーバーを使うなら Local network は残します。
- push させない：Git credentials と GitHub CLI credentials を切ると、サンドボックス内からの push と PR 作成が止まります。「差分は作らせるが公開は人がやる」運用が設定で作れます。
- 企業で配る：個人の設定はアプリが「要求する」ポリシーで、企業管理設定があると実際はより厳しくなります。組織で使うなら、まず企業側で「外で実行する」を禁止するかを決めてから、プロジェクトの既定を配る順番です。
注意点｜public preview・対象外の面・Linux の子プロセス
- public preview：公式は「変更の可能性がある」と明記しています。設定項目の名前や既定が変わる前提で、社内手順書には参照日を書いておきます。
- クラウドとリモートは対象外：ローカルサンドボックスは効きません。クラウド側は別の隔離の仕組みです。
- Linux の子プロセス：ローカルネットワークの制限は、シェルコマンドやローカル MCP・LSP の子プロセスには独立して効かないと書かれています。
- Windows：拒否パスの保証ができない環境ではコマンドが失敗します。CLI 側は Windows Insiders ビルドが条件です。
- CLI とアプリは別：どちらか一方で設定しても、もう一方には効きません。
失敗パターン 4 つ｜設定した気になって穴が開く場所
❌ 「Sandbox new sessions」をオンにして、動いているセッションが守られたと思う
設定は新しいセッションにしか効きません。⭕ 実行中のセッションは /sandbox on を入れるか、/restart-session で履歴を保ったまま再起動します。
❌ アプリで設定したから CLI も同じだと思う
アプリと CLI の設定は別管理です。⭕ CLI は /sandbox の 4 タブで別に設定し、企業管理の「(managed)」表示を確認します。
❌ 「Run outside the sandbox?」で「セッションの残りは無効」を押したまま忘れる
再起動か再接続まで無効のままです。⭕ 1 回だけ外で実行する選択肢を基本にし、無効にしたら「Re-enable sandbox」で戻します。企業で使うなら、管理設定で外での実行そのものを禁止できます。
❌ Linux でローカルネットワークを切ったので、ローカル MCP も外に出られないと思う
子プロセスには独立して効きません。⭕ ローカル MCP・LSP の通信はプロセス内の制限が届かない前提で、サーバー側の設定や別の隔離で補います。
よくある質問
Copilot アプリのローカルサンドボックスは既定でオンですか？
いいえ、既定はオフです。プロジェクトの設定で「Sandbox new sessions」をオンにすると、そのプロジェクトの新しいローカルセッションから効きます。実行中のセッションには /sandbox on で個別に効かせられます。
クラウドで動くセッションにも効きますか？
効きません。公式は「クラウドサンドボックスのセッションと、リモートホストで動くセッションには適用されない」と明記しています。ローカルリポジトリと working tree のセッションだけが対象です。
設定を変えたのに反映されないのはなぜですか？
ファイル・ネットワーク・認証情報の変更は、新しいセッションか既存セッションの再起動で反映されます。/restart-session を使うと履歴を保ったまま再起動できます。
OS が対応していない時はどうなりますか？
最初のサンドボックス付きシェルが起動する時に対応を確認し、強制できなければ unsupported-platform か unsupported-policy のメッセージで失敗します。サンドボックスなしで実行されることはありません。「Sandbox unavailable」が出たら問題を直して「Retry sandbox」を押します。
Copilot CLI のサンドボックス設定と共通ですか？
別管理です。CLI は /sandbox で開く General／Auth／Filesystem／Network の 4 タブで設定し、/sandbox enable・/sandbox disable で切り替えます。CLI 側には「Allow sandbox bypass」「Sandbox MCP servers」「Sandbox LSP servers」の項目もあります。
まとめ
Copilot アプリのローカルサンドボックスは、エージェントに shell を渡す時の「ファイル・ネットワーク・認証情報」の境界をプロジェクト単位で決める機能です。押さえるのは 4 点です。
- 既定はオフ。プロジェクトで「Sandbox new sessions」をオンにし、実行中は
/sandbox on。 - 強制できない環境ではエラーで止まり、サンドボックスなしでは走らない。
- クラウド・リモートは対象外、CLI は別管理。
- 外で走らせる操作は「1 回だけ」を基本に、企業では管理設定で禁止できる。
Claude Code・Codex CLI とも思想は同じで、違うのは既定の向きです。どれを使うにしても「隣のフォルダ」と「認証情報」から絞るのが、最初の 1 週間で事故を防ぐ順番だと考えています。
運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）
参考・出典
- GitHub Changelog「Local sandboxing in the GitHub Copilot app」（2026年9月23日・参照日 2026年9月24日）
- GitHub Docs「Configuring local sandboxing in the GitHub Copilot app」（参照日 2026年9月24日）
- GitHub Docs「Configuring local sandbox settings」（Copilot CLI・参照日 2026年9月24日）
- GitHub Docs「Understanding filesystem policies for local sandboxing in GitHub Copilot CLI」（参照日 2026年9月24日）
- Claude Code Docs「Configure the sandboxed Bash tool」（参照日 2026年9月24日）
- OpenAI「Agent approvals & security」（Codex のサンドボックスと承認・参照日 2026年9月24日）
