GitHub Copilot App ローカルサンドボックス設定ガイド

サンドボックスを有効にしたのに、既存セッションが古い権限のまま動く。あるいは、依存関係のインストール、ローカルサーバーへの接続、ブランチの push のたびに追加アクセスを求められる。こうした問題は、単なるオン／オフではなく、プロジェクト既定値、セッション上書き、ファイル・ネットワーク・認証情報の三つの境界が組み合わさって起こります。

このガイドを読み終えると、ローカルリポジトリやワークツリーに合う開始ポリシーを選び、変更を正しいセッションへ反映し、ダミーデータで制限を確認できます。最短の流れは、対象セッションの確認 → Sandbox new sessions の有効化 → 三つの権限を絞る → 新規作成または再起動 → 安全な確認、です。

GitHub は 2026 年 9 月 23 日にこの機能を発表しました。現在もパブリックプレビューのため、画面や挙動は変わる可能性があります。まず覚えるべき境界は、既定で無効、プロジェクト単位で設定、ホストがポリシーを強制できなければ保護なしで続行せずシェルが失敗する、の三つです。

まず現在のセッションが対象か確認する

このプロジェクトポリシーの対象は、ローカルリポジトリとローカルワークツリーのセッションだけです。クラウド、リモートホスト、GitHub Copilot CLI は別の仕組みを使うため、設定変更の前に表で範囲を確認してください。

セッションの種類	対象か	覚えておく境界
ローカルリポジトリのセッション	対象	現在のプロジェクトのサンドボックス設定を使用する
ローカルワークツリーのセッション	対象	ワークツリーはブランチとファイルを分離するが、マシン上の別の場所へのアクセスを制限しない。その権限境界をサンドボックスが提供する
クラウドサンドボックスのセッション	対象外	クラウドセッション固有の分離を使用する
リモートホスト上で動くセッション	対象外	ローカルプロジェクトのポリシーはリモートホストには適用されない
GitHub Copilot CLI	別途設定	Copilot app と Copilot CLI のサンドボックス設定は互いを置き換えない

企業管理の設定によって、実際に有効になるポリシーがプロジェクト設定で要求した内容より厳しくなることがあります。そのため、プロジェクト画面に表示されるのは app が要求する権限であり、組織が許可する最大権限と常に一致するとは限りません。

新しいセッションでサンドボックスを有効にする方法

今後のローカルセッションにプロジェクトポリシーを使わせるには、Sandbox new sessions をオンにした後、新しいセッションを開始する必要があります。スイッチだけでは実行中のセッションは変わりません。手順は次のとおりです。

1. GitHub Copilot app の設定を開きます。
2. 設定するプロジェクトを選びます。
3. Sandbox セクションを探します。
4. Sandbox new sessions をオンにします。
5. 新しいローカルセッションを開始します。

このスイッチが影響するのは、その後に作成したセッションだけです。すでに実行中のセッションは変更されません。ファイル、ネットワーク、認証情報のポリシーを後から変更した場合も、新しいセッションを開始するか、現在のセッションを再起動するまで反映されません。

会話履歴を保ったままポリシーを再読み込みするには、既存セッションで /restart-session を入力します。

GitHub は、ほとんどのプロジェクトでは既定ポリシーから始めることを推奨しています。既定ポリシーは、依存関係のインストール、ローカル開発サーバーへの接続、ブランチの push、プルリクエストの作成といった一般的な開発作業を想定しています。プロジェクトの近くに機密フォルダーがある、ネットワーク接続が不要、または自分の認証情報を使わせたくない場合は、必要な範囲まで絞り込みます。

ファイル・ネットワーク・認証情報を別々に絞る方法

三つは独立した制御です。ファイルを制限しても認証情報は無効にならず、認証情報を切っても読み取り可能な機密フォルダーは保護されません。タスクに合わせて一つずつ絞ってください。

1. ファイルシステム：読み取りと変更を許可する場所を決める

ファイル権限は最小範囲から始め、ワークスペースの読み書きを残し、必要な場合だけ外部パスを追加します。既定ではワークスペースと現在の作業ディレクトリを読み書きでき、設定には次の三つのリストがあります。

• Additional read/write：エージェントが実行するツールに、追加で読み取りと変更を許可するフォルダー。
• Additional read-only：読み取りは許可するが、変更は許可しない追加フォルダー。
• Denied：アクセスを許可しないフォルダー。

親フォルダーに広い読み取り権限や書き込み権限があっても、より具体的な子フォルダーを Denied に指定すれば、その子フォルダーは拒否されたままです。ホームディレクトリ全体を開き、多数の例外で守るより、必要なパスだけを狭く許可する方が安全です。

Windows には重要な強制境界があります。拒否パス自体はプロジェクト設定に保存できますが、使用中の Windows サンドボックス機能でその拒否を保証できない場合、コマンドは unsupported-policy メッセージで失敗します。パスを露出したまま処理を続けたり、サンドボックスを自動的に無効にしたりはしません。

2. ネットワーク：インターネットとローカルネットワークを分ける

依存関係の導入やローカル開発サーバーが必要なら、二つのネットワークをまとめて切らず、外向きインターネットとローカルネットワークを別々に判断します。既定では両方へ接続でき、次を制御できます。

• Outbound internet：GitHub、パッケージレジストリ、その他のインターネットサービスへのアクセス。
• Local network：ループバックとローカルネットワークへの接続。ローカル開発サーバーも含まれます。

ネットワークを制限すると、依存関係のインストール、API 呼び出し、プレビューサーバーなど、接続を必要とする作業に影響します。ネットワーク拒否は副作用のないスイッチではなく、タスク上のトレードオフとして扱う必要があります。

Linux には固有の制限があります。シェルコマンド、ローカル MCP サーバー、LSP サーバーなど、生成されたプロセスについては、サンドボックスがローカルネットワークアクセスだけを独立して制御できません。一方、プロセス内で行われる Web リクエストやリモート MCP 接続には設定が適用されます。Linux では一方だけを試すのではなく、プロセス内処理と生成プロセスの両方を確認してください。

3. 認証情報：Git と GitHub CLI を別々に制御する

コード閲覧やオフライン分析では、まず Git と GitHub CLI の認証情報を無効にし、push やプルリクエスト作成が必要なときだけ有効にします。既定では認証済み操作を利用でき、次を無効にできます。

• Git credentials：認証済み HTTPS Git 操作で使う認証情報。
• GitHub CLI credentials：GitHub CLI が使う認証情報。

無効にすると、ブランチの push やプルリクエストの作成などができなくなる場合があります。ファイルシステムと認証情報は別々の境界です。認証情報を無効にした場合でも、鍵、設定、その他の機密情報を含むディレクトリはファイルシステムルールで保護してください。

プロジェクト、現在のセッション、一回の操作をどう使い分けるか

今後のセッションへ継承させるならプロジェクト設定を変更し、現在のセッションだけなら /sandbox on または /sandbox off を使います。プロジェクト変更を現在のセッションに反映するには /restart-session を実行します。

操作	反映されるタイミング	他のセッションへの影響
プロジェクトの Sandbox 設定を変更	新しいセッション、または再起動後のセッション	そのプロジェクトで後から始めるセッションが継承する既定値を変更する
実行中のローカルセッションで /sandbox on	即時。そのセッションに永続する上書きとして有効	他のセッション向けのプロジェクト既定値は変えない
実行中のローカルセッションで /sandbox off	即時にそのセッションのサンドボックスを無効化	他のセッションは変わらない。以後のコマンドはユーザーアカウントと同じファイル、ネットワーク、認証情報へのアクセスを持つ
セッション開始前に /sandbox on または /sandbox off	新しいセッションが継承するプロジェクト既定値を変更	その後、当該既定値から開始するセッションに影響する
/restart-session	現在のセッションを再起動し、履歴を維持してポリシーを再読み込み	それ自体はプロジェクトポリシーを書き換えない

ツールがポリシーで許可されていないアクセスを必要とすると、app に Run outside the sandbox? と表示されることがあります。有効なポリシーによっては、キャンセル、その操作だけをサンドボックス外で一度実行、または現在のセッションの残り時間すべてでサンドボックスを無効化、のいずれかを選べます。企業の所有者は、ユーザーがツールをサンドボックス外で実行できないようにすることもできます。

このプロンプトから無効にしても、プロジェクト既定値や既存のセッション上書きは書き換わりません。一時状態は、セッションを再起動または再接続した時点で終了します。Sandbox off for this session と表示された後は、Re-enable sandbox で再び有効にできます。

判断するときは、まずキャンセルし、なぜ追加アクセスが必要なのかを確認するのが安全です。繰り返し必要なアクセスなら、プロジェクトポリシーを最小限だけ更新して再起動します。サンドボックス外で一度だけ実行するのは、コマンド、引数、影響を確認した後に限定してください。未知のリポジトリや、プロンプトから動的に組み立てられたコマンドでは、利便性だけを理由にセッション全体のサンドボックスを無効にしない方がよいでしょう。

ホストが強制できないポリシーではコマンドが停止する

OS が要求されたルールを強制できない場合、安全な結果はコマンドの失敗であり、自動的な非サンドボックス実行ではありません。

GitHub Copilot app は、OS が設定内容をすべて強制できるか判定する前でも、サンドボックス設定を受け付けます。実際の対応状況は、最初のサンドボックス化されたシェルを開始した時点で確認されます。

ホストが要求されたポリシーを強制できない場合は、次のようになります。

• シェルに unsupported-platform または unsupported-policy が表示されます。
• コマンドはサンドボックスなしで続行されません。
• app に Sandbox unavailable と表示された場合は、報告された問題を修正して Retry sandbox を選びます。

これはベストエフォート実行ではなく、安全側で失敗する挙動です。そのため、設定を保存できたことだけでは、現在のマシンでポリシーが有効になった証明にはなりません。少なくとも一度サンドボックス化されたシェルを開始し、未対応メッセージが出ないことを確認してから、最小限の動作確認を行ってください。

ダミーデータでポリシーを確認する方法

GitHub の説明は期待される挙動を示しますが、現在の OS とポリシーの組み合わせで実際に機能するかは、自分の端末で確認する必要があります。以下は破棄可能なフォルダーとダミーファイルを使うため、本物の鍵や本番設定に触れません。

ワークスペース外に破棄可能なテストフォルダーを作り、中にはダミーファイルだけを置きます。実際の SSH 鍵、クラウド認証情報、本番設定を使って試してはいけません。

確認項目	安全な手順	期待されるポリシー挙動
新規セッションへの継承	Sandbox new sessions を有効にし、新しいローカルセッションを作る	新しいセッションはプロジェクトポリシーを使い、古いセッションは自動では変わらない
ポリシー変更の反映	ルールを一つ変更し、/restart-session を入力する	セッションは履歴を保ったまま再起動し、ポリシーを再読み込みする
読み取り専用フォルダー	破棄可能なフォルダーを Additional read-only に追加し、ダミーファイルを読み、テストファイルの作成を試す	読み取りは成功し、変更は拒否されるはず
拒否フォルダー	別の破棄可能なフォルダーを Denied に追加し、一覧表示またはダミーファイルの読み取りを試す	親パスが許可されていてもアクセスが拒否されるはず
インターネット接続	Outbound internet を無効にし、無害な接続確認を行う	外部接続は失敗するはず。再度有効にして比較する
ローカルネットワーク	Local network を無効にし、破棄可能なローカルテストサービスに接続する	プラットフォームの能力に従う。Linux の生成プロセスに関する制限を考慮する
Git 認証情報	Git credentials を無効にし、テストリポジトリで変更を伴わない認証確認を行う	認証済み HTTPS Git 操作を利用できない場合がある
GitHub CLI 認証情報	GitHub CLI credentials を無効にし、gh auth status など変更を伴わない確認を行う	GitHub CLI は以前の認証能力を受け取らないはず。具体的なエラーは環境により異なる
安全側での失敗	unsupported-platform または unsupported-policy が出た場合、対象のダミーファイルが作成されていないことを確認する	コマンドはサンドボックスなしで続行されず、意図した副作用も発生しないはず

確認後はテストフォルダーを削除し、プロジェクトに本当に必要な最小限の権限だけを戻します。実際の機密ディレクトリへアクセスして、拒否ルールを証明しようとしてはいけません。

用途ごとにどの開始ポリシーを選ぶか

日常開発、未知のリポジトリ、オフライン分析に同じポリシーを使うべきではありません。通常作業では必要な機能を残し、未知のコードでは厳しく始め、オフライン作業ではまずネットワークと認証情報を切ります。

日常的な開発

サンドボックスを有効にし、既定のネットワーク能力と認証能力を維持します。必要な外部フォルダーだけを追加し、近接する機密ディレクトリは明示的に拒否します。依存関係のインストール、ローカルサービスの実行、ブランチの push、プルリクエスト作成を伴う通常の作業に向きます。

未知のリポジトリをレビューする場合

ワークスペースだけに読み書きを許可し、追加の参考資料は読み取り専用にします。Git と GitHub CLI の認証情報は既定で無効にし、依存関係の取得元を理解するまで外向きインターネットも無効にします。一時的なアクセスが必要でも、すぐに /sandbox off を使うのではなく、特定の能力だけを開きます。

ローカルでのオフライン分析

外向きインターネットと不要な認証情報を無効にし、必要なファイルアクセスだけを残します。ローカルネットワーク分離も重要なら、Linux では生成プロセスの挙動を別途確認し、一つの UI スイッチですべてのプロセスを同じように制御できると仮定しないでください。

これらは GitHub が名称を付けたプリセットではありません。GitHub が公開している権限の軸から組み立てた開始例です。最終的なポリシーは、リポジトリ、OS、企業ルール、実際のタスクに合わせてください。

ポリシーを無効化・過剰許可しやすい誤り

最も多い誤りは、「設定を保存した」を「ポリシーが強制された」と考えることと、最初の拒否でサンドボックス全体を切ることです。次の七項目は確認を無効にしたり、不要な権限を与えたりします。

1. ワークツリーをセキュリティ境界と考える。 ワークツリーは並行するブランチとファイルを分離しますが、コマンドがマシン上の他の場所に到達することまでは防ぎません。
2. ポリシーを変更した後も古いセッションで確認を続ける。 プロジェクト変更は遡って反映されません。新しいセッションを開始するか、/restart-session を使います。
3. app と CLI が一つのサンドボックスを共有すると考える。 両者は別々に設定します。
4. 設定を保存できたことをホスト対応の証明と考える。 強制可能かどうかは、最初のサンドボックス化されたシェル開始時に確認されます。
5. /sandbox off の意味を見落とす。 エージェントが実行するコマンドは、その後ユーザーアカウントと同じ範囲へアクセスできます。
6. ネットワーク挙動がすべての OS で同じだと考える。 Linux には、生成プロセスのローカルネットワーク制御に文書化された制限があります。
7. アクセス拒否のたびに広いバイパスを使う。 通常は必要性を確認し、最小のポリシー変更を行い、セッションを再起動する方が安全です。

次に行うこと

まずローカルリポジトリまたはローカルワークツリーのセッションであることを確認し、Sandbox new sessions を有効にします。日常開発は既定ポリシーから始め、必要なフォルダー、ネットワーク、認証情報だけを残します。未知のコードやオフライン分析では、より厳しいポリシーから一つずつ権限を追加してください。

プロジェクトポリシーを変更したら、新しいセッションを作るか /restart-session を実行し、破棄可能なデータで読み取り専用、拒否、ネットワーク、認証情報を確認します。unsupported-platform、unsupported-policy、Sandbox unavailable が出た場合は互換性を解決し、/sandbox off の結果をサンドボックス成功と扱わないでください。

公式リファレンス

設定の前後で、現在の画面、適用範囲、失敗時の挙動を以下の GitHub 公式ページで確認できます。

• GitHub Copilot app でローカルサンドボックスを設定する
• Local sandboxing in the GitHub Copilot app — GitHub Changelog、2026 年 9 月 23 日