メモ
GitHub Copilotのローカル サンドボックスはパブリック プレビューにあり、変更される可能性があります。
重要
Windowsでのローカル サンドボックスには、Windows Insider ビルドが必要です。
イントロダクション
ローカル サンドボックスを有効にすると、 Copilot CLI はオペレーティング システムサンドボックス内でユーザーの代わりに呼び出すコマンドを実行します。 サンドボックスは ファイルシステム ポリシーを適用します。これは、サンドボックス化されたプロセスまたは操作が読み取ることができるパス、書き込み可能なパス、およびまったく触れることができないパスを決定する一連のルールです。
このポリシーのほとんどは自動的に組み立てられるため、毎日のコマンドはセットアップなしで動作し続けます。 この記事では、 Copilot がポリシーに到達する方法と、特定のディレクトリで付与されるアクセス権を確認する方法について説明します。
ローカル サンドボックスの概要 (オンとオフの方法など) については、 クラウドサンドボックスとローカルサンドボックスについて GitHub Copilot と ローカル サンドボックスの利用 を参照してください。
ポリシーの適用対象
ファイルシステム ポリシーは、ユーザーに代わって行う作業 Copilot を対象としますが、作業の種類に応じてさまざまな方法で適用されます。
- シェル コマンドと組み込み検索は 、セキュリティで保護された子プロセスとして実行されるため、オペレーティング システムによってポリシーが直接適用されます。 たとえば、
grepツールとglobツールは、サンドボックス化された子プロセスとして ripgrep を実行します。 - ローカル MCP および言語サーバー プロセス (LSP) もサンドボックス内で実行できるため、オペレーティング システムによってポリシーも適用されます。
- 組み込みのファイル読み取りツールとファイル編集ツール は、サンドボックスの子プロセスとしてではなく、 Copilot CLI 自体の一部として実行されます。 ファイルの読み取りまたは書き込み前に同じファイルシステム ポリシーを確認しますが、オペレーティング システムサンドボックスではこれらの操作が表示されないため、チェックはオペレーティング システムが適用するものではなく、ソフトウェア専用のセーフガードです。
- リモート MCP サーバー はコンピューターの外部で実行されるため、サンドボックスに対するローカルの子プロセスはなく、ファイル システム ポリシーでは制約されません。
- サブエージェントは 直接動作しません。他のツールを調整します。 ポリシーが適用されるかどうか、および適用方法は、サブエージェントが呼び出すツールによって異なります。
そのため、サンドボックス 化されたプロセス はオペレーティング システムによって制限されますが、インプロセス 操作 ではソフトウェアで同じポリシーが適用されます。そのため、この記事ではコマンドだけでなく、サンドボックス化されたプロセスまたは操作を参照します。
アクセス許可レベル
サンドボックスは 既定で拒否されます。パスが明示的に付与されていない限り、コマンドで使用することはできません。 ポリシー内のすべてのパスには、次の 3 つのアクセス許可レベルのいずれかが含まれます。
- 読み取り/書き込み — コマンドは、このパスにあるファイルの読み取りと変更を行うことができます。
- 読み取り専用 — コマンドは、このパスにあるファイルを読み取ることができますが、変更することはできません。
- 拒否 - より広範な規則で許可される場合でも、コマンドはこのパスで読み取りまたは書き込みを行うことはできません。
アクセスが許可されない限り、アクセスは拒否されるため、 Copilot は、プロジェクト ファイル、実行するツール、一時ディレクトリなどのサポートの場所など、正当に必要なものをすべてコマンドに付与する必要があります。ただし、それ以外はすべて制限を受けないようにします。
メモ
これらのアクセス許可レベルはすべてのサンドボックス 化されたプロセスまたは操作に適用されますが、適用方法は異なります。サンドボックス化された子プロセスの場合、オペレーティング システムによって直接適用されますが、CLI の組み込みのファイル読み取りとファイル編集ツールは、オペレーティング システムのバックストップなしで、ソフトウェア内で同じレベルをチェックします。
ポリシーの構築方法
各サンドボックス プロセスが開始される前に、 Copilot CLI は、現在の作業ディレクトリ、環境、設定、自動許可を使用して、そのプロセスの有効なポリシーを解決します。 これにより、プロセスは必要なアクセスのみに制限され、これらの共通の場所を自分で管理する必要がなくなります。
作業ディレクトリ
既定では、ローカル サンドボックスのファイルシステム設定で [作業ディレクトリを含める] が有効になっている場合、現在の作業ディレクトリには読み取り/書き込みアクセス権が付与されます。 Git リポジトリでは、 Copilot 関連付けられている Git 許可も追加します。 この設定をオフにすると、これらの自動付与がすべて抑制されるため、必要なプロジェクトと Git パスの許可規則を手動で追加する必要があります。 「ローカル サンドボックス設定の構成」を参照してください。
メモ
エンタープライズ所有の組織から Copilot を取得した場合、管理者は [ 作業ディレクトリを含める ] 設定をオフにしてロックできるため、有効に戻すことはできません。 「エンタープライズ管理設定」を参照してください。
PATH にあるツール
pythonやgitなどのプログラムを実行するには、サンドボックスでプログラムが存在するディレクトリをコマンドに表示する必要があります。
[開発ツールへのアクセスを許可する] が既定で有効になっている場合、Copilotは、PATH環境変数に一覧表示されているディレクトリと、GOPATH、JAVA_HOME、PYTHONPATHなどの関連ツール変数によって名前付けされたディレクトリへの読み取り専用アクセスを許可します。 読み取り専用は外部ツールに適したレベルです。コマンドを変更せず、 git実行する必要があります。 [ 開発ツールのアクセスを許可する] をオフにすると、これらのディレクトリは自動的に付与されなくなり、独自の許可ルールから取得する必要があります。 サンドボックスが検査する PATH 環境変数とツールチェーン環境変数の完全な一覧と、それぞれの解釈方法については、 GITHUB COPILOT CLI コマンド リファレンス を参照してください。
システムとプロファイルの場所
macOS では、コマンドが共有ライブラリを読み込み、システム設定を参照できる一方で、それらを変更できないように、標準的なシステム領域は読み取り専用に設定されています。 ユーザー プロファイル内のアプリケーション ディレクトリは、 開発ツールへのアクセスを許可 する場合にも読み取り専用で付与されるため、コマンドは変更しなくても、そこにインストールしたツールを読み取ることができます。
パッケージ マネージャー キャッシュ
インストールとビルドをサンドボックス内で動作させるために、 Copilot は、一般的なパッケージ マネージャーとツールチェーンによって使用されるキャッシュとレジストリへのアクセスも許可します。ほとんどの場所では読み取り専用、ビルド キャッシュやパッケージ マネージャー依存関係ストアなど、選択した書き込み可能な場所の読み取り/書き込みも許可されます。
/sandbox policy レポートでは、これは開発ツール アクセスとして表示されます。
Git リポジトリ
Git リポジトリのサブディレクトリで作業する場合、Copilotはリポジトリ全体への読み取りアクセス権を付与し、コマンドがプロジェクト全体を表示できるようにしながら、現在の作業ディレクトリとリポジトリの Git メタデータ (.git ディレクトリ) への書き込みを制限します。 これにより、コマンドはリポジトリ全体を読み取りますが、変更は作業している場所に集中できます。
読み取りアクセスはリポジトリ全体にまたがるため、サンドボックス コマンドは、プロジェクト内の他の場所に格納されている機密性の高いものも含め、現在のサブディレクトリの外部にあるファイルを読み取ることができます。 特定のパスにアクセスできないようにするには、拒否ルールを追加できます。 「ローカル サンドボックス設定の構成」を参照してください。
アクセス 規則が重複する場合
Copilotは複数の場所を許可し、独自の場所を追加できるため、ルールは重複する可能性があります。 そうすると、 より具体的なパスが優先されます。 たとえば、/project が書き込み可能であっても、/project/secrets を読み取り専用としてマークすると、/project 内では /project/secrets を除くすべてが書き込み可能なままです。 これは、機密性の高いサブフォルダーを保護する便利な方法です。
便宜上の許可が妨げになる場合でも、重複はユーザーに有利な形で解決されます。
PATHに表示されるローカル仮想環境 (.venv) を持つPython プロジェクトについて考えてみましょう。 そのディレクトリを通常の読み取り専用ツールの場所として扱うと、書き込み可能なプロジェクト内に配置されていても読み取り専用になり、環境を更新しようとしたときに pip install などのコマンドが失敗する可能性があります。
Copilot はこれを解決します。自動的に追加されたアクセス許可（PATH 上のツール ディレクトリなど）は、それをすでにカバーしている、より広範な読み取り/書き込みアクセス許可に置き換えられます。 そのため、プロジェクトローカルの .venv、 node_modules/.bin、または同様のディレクトリは、ワークスペースの一部として書き込み可能なままです。
ユーザーが設定したルールは常に保持されます。 パスを読み取り専用に設定するか拒否すると、後で同じパスが検出されて本来であれば自動的に許可される場合でも、その設定は有効のままです。 これにより、機密性の高い場所を保護するための確実な方法が得られます。たとえば、サンドボックス化されたコマンドが秘密情報を読み取れないように、.env ファイルへのアクセスを拒否できます。
現在のポリシーで許可されている内容を確認する
ポリシーはディレクトリとコマンドごとに組み立てられるため、アクセス権を確認する最も簡単な方法は、 Copilot CLIを要求することです。 セッションで、次のように入力します。
/sandbox policy
/sandbox policy
Copilot は、現在のディレクトリの 有効な ポリシー (ここから起動されたコマンドが実際に受け取る読み取り/書き込み、読み取り専用、拒否されたパス) と、ネットワーク アクセスと開発ツールアクセスを強制的に出力します。 これは、自動許可と独自の設定が組み合わされ、保存された設定のコピーだけでなく、重複が解決された後に解決された結果です。
レポートを読むときに留意すべき点がいくつかあります。
- 現在のディレクトリが反映されます。 権限はディレクトリごとに検出されるため、同じ設定でも、実行する場所によって異なるパスに解決される場合があります。
- 構成したパスがディスク上に存在しない場合は、ポリシーから除外され、[ メモ ] セクションに記載されています。 これは、追加したルールが効果を持たないように見える理由を説明します。
- サンドボックスが無効になっている場合、
/sandbox policyはポリシーを印刷するのではなく、制限が適用されないため、そのように指示します。
サンドボックスが現在オンになっているかどうかを確認するには、 /sandbox statusを使用します。 これらのコマンドの詳細については、 AUTOTITLE を参照してください。
ポリシーのカスタマイズ
追加の読み取り/書き込みまたは読み取り専用パスの付与、パスの拒否、その他のファイルシステムの動作の変更は、 /sandbox config ダイアログまたは設定ファイルから行うことができます。 変更を加えた後、 /sandbox policy を実行して結果を確認します。 詳細な手順については、 ローカル サンドボックス設定の構成 を参照してください。
エンタープライズ管理ポリシー
エンタープライズ所有の組織を通じて Copilot を取得した場合、管理者はマネージド設定を使用してファイルシステム ポリシーを適用できます。 マネージド設定は、制限の厳しいベースラインとして機能します。サンドボックス化を要求したり、拒否されたパスを追加したり、許可するパスを制限したりできます。 管理設定が適用される場合、 /sandbox config ダイアログにはロックされた (マネージド) 値として表示され、 /sandbox policy は解決されたポリシーに反映されます。 有効なポリシーでサンドボックス のバイパスが許可されている場合、ユーザーはアクティブなバイパスアクセス許可プロンプトから、現在のセッションの残りの部分のサンドボックスを明示的に無効にすることができます。 このセッションのオプトアウトでは、保存されたポリシーは緩まれません。
1 つのソースが優先されるほとんどの設定とは異なり、サンドボックス ポリシーは、すべてのソースから一度に強制的に構成されます。 管理対象の設定は、サーバー管理型、MDM、ファイルベースなど複数の経路から同時に適用される場合があり、これらは相互に、さらにユーザー自身の設定とも組み合わされます。その際、あるソースが別のソースを上書きするのではなく、最も制限の厳しい 方向で適用されます。つまり、必須のトグルはオンのまま維持され、すべてのソースで拒否されたパスは合算され、許可できるパスの範囲は狭まることはあっても広がることはありません。 詳細については、「エンタープライズ管理設定」を参照してください。