OSが守れないなら実行しない──GitHub Copilotアプリにローカルサンドボックスがパブリックプレビュー追加

GitHub公式Changelogによると、GitHub Copilotアプリ(GitHub公式ドキュメントが「エージェント主導の開発向けのデスクトップアプリケーション」と説明する製品)に、2026年9月23日付で「ローカルサンドボックス(Local sandboxing)」がパブリックプレビューとして追加された。ローカルのリポジトリ・ワーキングツリーセッションを対象に、ファイル・ネットワーク・認証情報へのアクセスをプロジェクト単位で制限できる機能で、既定はオフ。プロジェクト設定でオンにするか、稼働中のセッションに/sandbox onと打てば、そのセッションだけに個別適用できる。GitHub公式ドキュメントによれば、要求したポリシーをOSが強制できない場合、サンドボックス無しで実行することはなく、サンドボックス化されたシェルがエラーで失敗する設計になっている。

3行まとめ

1. GitHub Copilotアプリに2026年9月23日、ローカルのリポジトリ・ワーキングツリーセッション向けの「ローカルサンドボックス」がパブリックプレビュー追加。ファイル(追加read/write・追加read-only・拒否の3リスト)・ネットワーク(outbound internet・ローカルネットワーク)・認証情報(Git HTTPS・GitHub CLI)の3系統をプロジェクト単位で制限できる。既定はオフ。
2. GitHub公式ドキュメントによると、実装は「Microsoft eXecution Container(MXC)」という、各OSの隔離機構に共通のインターフェースを与える技術。要求したポリシーをOSが強制できない場合、GitHub公式Changelogは「サンドボックス無しで実行するのではなく、エラーで失敗する」という趣旨を明記し、公式設定ガイドはunsupported-platform/unsupported-policyというエラーメッセージで停止すると具体化している。
3. 稼働中セッションには/sandbox onでプロジェクト既定を変えずに個別適用できる。逆に許可範囲外の操作が必要になった場面では「Run outside the sandbox?」というプロンプトが出ることがあり、有効なポリシーに応じて、キャンセル・今回だけ許可・セッション中オフの中から選べる、と公式設定ガイドは説明している。

ChangelogとGitHub公式ドキュメントから拾った事実

何を制限できるのか──ファイル・ネットワーク・認証情報の3系統

GitHub公式の設定ガイドによると、既定ではサンドボックス化されたセッションはワークスペースとカレントワーキングディレクトリへの読み書きアクセスを持つ。そのうえで、依存関係のインストール・ローカル開発サーバーへの接続・ブランチのpush・プルリクエストの作成といった「一般的な開発作業」は既定のまま通る、とされている。

プロジェクト設定から変更できるのは次の3系統だ。

• ファイルシステム: 「追加read/write」「追加read-only」「拒否(denied)」の3つのフォルダリストを個別に設定する。より限定的な拒否フォルダは、より広い親フォルダに読み取りまたは書き込みの権限があっても拒否のまま、と明記されている。
• ネットワーク: 「outbound internet(インターネットへの発信)」と「ローカルネットワーク(ループバック・ローカル開発サーバーへの接続を含む)」を、それぞれ既定は許可のまま個別にオフにできる。ただしGitHub自身が注記しているとおり、Linux環境では、シェルコマンドやローカルのMCP・LSPサーバーのような「spawnされたプロセス」に対してローカルネットワークアクセスを個別制御できない。この設定は、Webリクエストやリモート MCP 接続のような「プロセス内の操作(in-process operations)」には引き続き適用される、とされている。
• 認証情報: 「Git認証情報(HTTPS経由のGit操作を許可)」「GitHub CLI認証情報(gh CLIの認証を許可)」を、それぞれ既定は許可のまま個別にオフにできる。オフにすると、サンドボックス内からのブランチpushやプルリクエスト作成が妨げられることがある、との注記がある。

Windows固有の挙動として、保存した拒否パスをアクティブなWindowsサンドボックスの機能では保証できない場合、拒否したパスにアクセスできる状態で実行するのでもサンドボックス無しで実行するのでもなく、サンドボックス化されたコマンドが「unsupported-policy」というメッセージで失敗する、とも記載されている。

既定はオフ、有効化は2つの経路

有効化の方法は2つに分かれる。

1. プロジェクトの既定として: アプリ設定でプロジェクトを選び、「Sandbox」欄の「Sandbox new sessions」をオンにする。この変更はそのプロジェクトの新しいセッションにのみ適用され、既に動いているセッションは変わらない。ファイル・ネットワーク・認証情報の設定変更も同様に、新しいセッションが始まるか、既存セッションが再起動したときに反映される(/restart-sessionで履歴を保ったまま再起動できる)。
2. 稼働中の個別セッションとして: アクティブなローカルセッションで/sandbox on(オフにする場合は/sandbox off)と打つと、そのセッションに対する永続的な上書きとして即座に適用される。プロジェクトの既定設定自体は変わらない。セッション開始前にこのコマンドを打った場合は、新しく継承されるプロジェクト既定そのものを変える、という違いもある。

OSが守れなければ、サンドボックス無しでは動かさない

この機能の設計で最もはっきりしているのが、失敗時の挙動だ。GitHub公式Changelogは本文中に、次の一文を独立した段落として置いている。

If your operating system cannot enforce the requested policy, the sandboxed shell fails with an error rather than running without a sandbox. (訳: OSが要求されたポリシーを強制できない場合、サンドボックス化されたシェルは、サンドボックス無しで実行されるのではなく、エラーで失敗する。)

公式の設定ガイドは、この挙動をもう少し具体的に説明している。

The app accepts sandbox settings before checking whether your operating system can enforce them. Support is checked when the first sandboxed shell starts. If the host cannot enforce the requested policy, the shell fails with an unsupported-platform or unsupported-policy message and does not run unsandboxed. (訳: アプリはOSが設定を強制できるかどうかを確認する前に、サンドボックス設定を受け付ける。対応状況は最初のサンドボックス化されたシェルが起動する際に確認される。ホストが要求されたポリシーを強制できない場合、シェルはunsupported-platformまたはunsupported-policyというメッセージで失敗し、サンドボックス無しでは実行されない。)

アプリに「Sandbox unavailable」と表示された場合は、問題に対処したうえで「Retry sandbox」をクリックする必要がある、とも記載されている。

ポリシーの外に出たい時にできること

OSレベルで強制できないケースとは別に、稼働中のサンドボックスが許可していない操作をツールが必要とした場合には、アプリが「Run outside the sandbox?」というプロンプトを表示することがある、とも説明されている。有効なポリシーに応じて、示される選択肢は次のとおり。

• 操作をキャンセルする
• その操作だけ、1回に限りサンドボックスの外で実行する
• 現在のセッションの残り時間について、サンドボックスを無効化して実行する

このプロンプトからサンドボックスを無効化すると、アプリには「Sandbox off for this session」と表示され、「Re-enable sandbox」をクリックすれば再度有効化できる。一時的な無効化はプロジェクトの既定やセッションの上書き設定そのものを変えるものではなく、セッションが再起動・再接続されると終了する。また、エンタープライズのオーナーは、この「サンドボックス外での実行」自体をユーザーに使わせない設定にできる、とも記載されている。

Claude Code・Codexのサンドボックスと並べると

エージェントに危険なコマンドを実行させたくない層にとって、この機能は単体で読むより、他社のコーディングエージェントが既に持つサンドボックス機構と並べて読んだほうが特徴がはっきりする。Claude Code公式ドキュメントの「サンドボックス化されたBashツール」、Codex公式ドキュメントの「Sandbox」「Agent approvals & security」の各ページを確認した範囲では、次のように整理できる。

この記事を書くために3社の公式ドキュメントを並べて読んで気づいたのは、「OSがポリシーを守れない・守らせられない」場面での既定挙動が、文書で確認できたGitHub Copilotアプリ(今回の機能)とClaude Codeとで逆向きだという点だ。Claude Codeは、依存パッケージ不足や非対応プラットフォームでサンドボックスを起動できない場合、既定では警告を出したうえでサンドボックス無しのまま処理を続け、止めるには利用者がfailIfUnavailableを明示的にオンにする必要がある。対してGitHub Copilotアプリの今回の機能は、その逆──既定のまま「守れないなら止める」を選んでいる。どちらが優れているという話ではなく、同じ「サンドボックス」という名前の機能でも、既定値の向きが逆になっている、という構図だ。なお同じGitHubでも、Copilot CLIのローカルサンドボックスは、ホストが対応していない場合はそのセッションのサンドボックスをオフにして通知を出し、サンドボックス無しで実行する(企業がデバイス管理設定でサンドボックスを強制している場合は実行しない)、とGitHub公式ドキュメントは説明している。「止める」はCopilotアプリ側の既定で、GitHub製品全体の既定ではない。ネットワークの既定についても、Codexは既定オフ、GitHub Copilotアプリは既定オン(必要に応じて個別オフ)と、逆方向になっている。

この記事の確認範囲

この記事はGitHub公式Changelog本文と、そこからリンクされている公式設定ガイド、および関連する2本の公式ドキュメントページを一次資料としている。GitHub Copilotアプリ自体は今回の執筆にあたってインストール・起動しておらず、「Sandbox new sessions」のトグルや「Run outside the sandbox?」プロンプトの実際の見た目・文言は、公式ドキュメントに書かれた記述をそのまま引いたものであり、実機のスクリーンショットではない。

Claude Code・Codexについても同様に、各社の公式ドキュメントの記述を根拠にしており、実際に3つのツールで同じ操作(たとえばOSのサンドボックス機構を無効化した状態でコマンドを実行する)を試して挙動を突き合わせたわけではない。表中の「Codexの、OSがポリシーを強制できない場合の挙動」で結論を書いていないのは、確認した2本のCodex公式ドキュメントには起動時の警告についての記述しかなく、その後の実行可否を名指しした記述を見つけられなかったためで、「そのような設計が存在しない」という意味ではない。

参照したGitHub・Anthropic・OpenAIの7ページ

• Local sandboxing in the GitHub Copilot app（GitHub公式Changelog、2026年9月23日）: https://github.blog/changelog/2026-09-23-local-sandboxing-in-the-github-copilot-app/
• Configuring local sandboxing in the GitHub Copilot app（GitHub公式ドキュメント）: https://docs.github.com/en/copilot/how-tos/github-copilot-app/configure-local-sandboxing
• About the GitHub Copilot app（GitHub公式ドキュメント）: https://docs.github.com/en/copilot/concepts/agents/github-copilot-app
• About cloud and local sandboxes for GitHub Copilot（GitHub公式ドキュメント）: https://docs.github.com/en/copilot/concepts/security-governance-and-network-settings/about-cloud-and-local-sandboxes
• Configure the sandboxed Bash tool（Claude Code公式ドキュメント）: https://docs.claude.com/en/docs/claude-code/sandboxing
• Sandbox（Codex公式ドキュメント）: https://learn.chatgpt.com/docs/sandboxing
• Agent approvals & security（Codex公式ドキュメント）: https://learn.chatgpt.com/docs/agent-approvals-security

いずれも2026年9月25日(日本時間)時点でアクセスして内容を確認した。GitHub Copilotアプリはパブリックプレビューの機能であるため、この記事が引用した挙動や文言は今後変更される可能性がある。

関連記事

• copilot --acpの1行でIDEから呼び出せる──GitHub Copilot CLIがACP対応をパブリックプレビュー化
• GitHub Copilot 使い方・料金・効果は本当にある？【2026年版】
• Claude Code・Codex・Devin──「APIキーを配らない」認証への移行が同時に進んでいる
• Claude Codeのサンドボックス化Bashツール──ファイルと通信をOSレベルで閉じ込める