GitHub Copilot CLI の構成ディレクトリ

Copilot CLI では、構成、セッション履歴、ログ、カスタマイズがコンピューター上の 1 つのディレクトリに格納されます。 既定では、このディレクトリは ~/.copilot (つまり、 $HOME/.copilot) です。

この記事では、このディレクトリの内容とその使用方法について説明します。

ディレクトリの概要

~/.copilot ディレクトリには、次の最上位項目が含まれています。

ユーザーが編集可能なファイル

次のファイルは、ユーザーが直接編集するか、CLI コマンドを使用して管理するように設計されています。

settings.json

これは、 Copilot CLIのプライマリ構成ファイルです。 セッション内では、対話型の /settings コマンドを使用して特定の値を変更したり、 /settings KEY VALUE を実行して 1 つの値を設定したりできます。 「/settings コマンドを使用して設定を変更する」を参照してください。 または、テキスト エディターで settings.json ファイルを直接編集することもできます。 このファイルは、コメント付き JSON (JSONC) をサポートしています。

既定では、このファイルはユーザー レベルの構成ディレクトリである ~/.copilot ディレクトリにあります。 これには、すべてのリポジトリのグローバル ユーザー レベルの既定値が含まれています。 このディレクトリの場所を変更するには、 COPILOT_HOME 環境変数を別のパスに設定します。

settings.jsonが読み取り、解析、または検証に失敗した場合、Copilot CLIは無効な値を無視し、**** コマンドの /settings タブへ誘導する起動時の警告をタイムラインに表示します。 そのタブを開いて特定のエラーを表示し、報告された問題を修正して、影響を受ける設定を復元します。

認識されない設定 (入力ミスなど) ではない最上位のキーがsettings.jsonに含まれている場合は、タイムラインまたは stderr ではなく、/settings コマンドの [問題] タブに一覧表示Copilot CLI。 タブのラベルには、構成スコープに問題がある場合の数 (たとえば、 Problems (2)) が表示されます。 $schema は許容され、報告されません。

~/.copilot/settings.jsonがシンボリック リンクである場合 (たとえば、dotfiles リポジトリを介して設定を同期する場合)、/settings コマンドからの書き込みは、シンボリック リンクを通常のファイルに置き換えるのではなく、シンボリック リンクに従ってターゲットを更新します。

設定の完全な一覧と、リポジトリ レベルの構成との対話方法については、この記事で後述する 構成ファイルの設定 を参照してください。

セッションの外部で、シェルから copilot config を使用して非対話形式で設定を読み取ったり変更したりします。これは /settings スラッシュ コマンドに対応するスクリプトです。 ユーザー設定ファイルではなく、.github/copilot/settings.json または .github/copilot/settings.local.json をターゲット --repo または --local に追加します。リポジトリでオーバーライド可能なキーのみを書き込むことができます。 完全なコマンド リファレンスについては、 GITHUB COPILOT CLI コマンド リファレンス を参照してください。

copilot-instructions.md

作業しているプロジェクトに関係なく、すべてのセッションに適用される個人のカスタム指示。 このファイルはリポジトリ レベルの copilot-instructions.md と同じように動作しますが、グローバルに適用されます。

詳細については、「GitHub Copilot用のリポジトリカスタム命令の追加」を参照してください。

instructions/

追加の個人用命令ファイルを *.instructions.md ファイルとしてここに格納します。 これらは copilot-instructions.md と共に読み込まれ、すべてのセッションに適用されます。 ~/.copilot/instructions/code-style.instructions.mdなど、トピックごとに手順を整理できます。

mcp-config.json

ユーザー レベルで使用できる MCP (モデル コンテキスト プロトコル) サーバーを定義します。 これらのサーバーは、使用しているプロジェクト ディレクトリに関係なく、すべてのセッションで使用できます。 Projectレベルの MCP 構成 (.mcp.json または .github/mcp.json) は、サーバー名の競合時にユーザー レベルの定義よりも優先されます。

詳細については、「GitHub Copilot CLI 用の MCP サーバーを追加する」を参照してください。

lsp-config.json

ユーザー レベルで使用できる言語サーバー プロトコル (LSP) サーバーを定義します。 これらのサーバーは、エージェントに言語インテリジェンス (診断、完了など) を提供します。 /lspスラッシュ コマンドを使用してこのファイルを管理するか、直接編集します。

詳細については、「GitHub Copilot CLI 用の LSP サーバーの追加」を参照してください。

providers.json

bring your-own-key (BYOK) プロバイダーとモデルのレジストリを、 providers キーと models キーを持つ JSON オブジェクトとして定義します。 このファイルが任意のプロバイダーまたはモデルを宣言する場合は、レガシ COPILOT_PROVIDER_* 環境変数よりも優先されます。

既定では、このファイルは ~/.copilot/providers.jsonにあります。 その場所を COPILOT_PROVIDERS_CONFIG 環境変数でオーバーライドします。

このファイル内のモデルは、Copilot サブスクリプションによって提供されるモデルに加えて利用できます。 ファイルを手動で編集した後、Copilot CLIを再起動して変更を読み込んでください。 セットアップの手順については、「GITHUB COPILOT CLI への LLM モデルの追加」をご覧ください。

プロバイダーの構成

コメントや末尾のコンマを使用せずに JSON オブジェクトを使用します。 ファイルには 2 つの配列が含まれています。 各プロバイダーは接続を定義し、各モデルはそれらのプロバイダーの 1 つを名前で参照します。 次の表では、 [] は配列内のエントリを意味します。 たとえば、models[].capabilities.supports.vision は、モデル エントリ内の vision 内の capabilities 内にある supports 設定です。

存在しないファイルまたは空のファイル、またはプロバイダーまたはモデルエントリのないファイルを使用すると、CLI は COPILOT_PROVIDER_* 環境変数にフォールバックできます。 いずれかの配列の値が null の場合は、空の配列として扱われます。 無効な JSON または無効なプロバイダーまたはモデル エントリを含むファイルでは、代わりに構成エラーが発生します。

CLI の起動時に構成済みのモデルを使用するには、PROVIDER-NAME/MODEL-ID を --model オプションに指定します。 PROVIDER-NAME はプロバイダーの name 値であり、 MODEL-ID はモデルの id 値です。 たとえば、 copilot --model local/qwen3:8bを実行します。 または、対話型セッション中に、/model を入力し、ピッカーからモデルを選択することもできます。

このファイルは、 Copilot CLIで使用するための接続、モデル機能、およびモデル命令を構成します。 このファイル内の JSON は、プロバイダー API 要求本文ではありません。 このファイルに設定を追加しても、設定はプロバイダーに渡されません。

プロバイダー設定

providersの各エントリは、次のフィールドを受け入れます。 必要なのは常にnameとbaseUrlだけです。 認証要件はプロバイダーによって異なります。

名前付きプロバイダー ファイルは、 apiKeyCommandをサポートしていません。 資格情報またはトークン更新コマンドは、 metadata または localModel.argsに配置しないでください。

ローカル モデル サーバーの設定

これらの設定は、 providers[].type が "local_model" され、 baseUrl が .gguf ファイルへのパスである場合にのみ適用されます。 CLI は、モデルが最初に使用されたときに開始されますllama-server。 実行可能ファイルをインストールし、PATHで利用可能にする必要があります。 CLI を起動するディレクトリに依存しないように、絶対モデル パスを使用します。

baseUrlが HTTP または HTTPS URL の場合、CLI はその既存のサーバーに接続し、これらのスタートアップ設定を使用しません。 また、Ollama やその他の OpenAI 互換サーバーも設定しません。

providers[].localModel内のすべてのフィールドは省略可能です。

CLI は、サーバーのモデル パス、ホスト、ポートを管理します。 argsなどのフォームを含め、--port=8080、--model、-m、または--hostを--port経由で渡すことはできません。

モデルの設定

modelsの各エントリは、次のフィールドを受け入れます。 idとproviderのみが必要です。

3 つのトークン制限フィールドは、 0 から 4294967295までの整数を受け入れます。 制限を無効にする方法として 0 に依存するのではなく、デプロイに適した正の値を使用します。 これらの設定は、使用する上限を CLI に指示しますが、モデルの実際の容量は増やしません。

モデル機能

models[].capabilities オブジェクトはモデルを記述します。 機能を true に設定しても、その機能をサポートしていないモデルには追加されません。

すべての機能フィールドは任意です。 オブジェクトはモデルの既定値にマージされ、配列は対応する既定の配列に置き換えられます。

サポートされているモデル機能

次のフィールドは、 models[].capabilities.supports内に属しています。

adaptive_thinking値の意味は次のとおりです。

reasoning_effortの場合、CLI は"none"、"minimal"、"low"、"medium"、"high"、"xhigh"、および"max"を認識します。 ["low", "medium", "high"] など、モデルでサポートされているレベルのみを一覧表示してください。 省略されたリストまたは空のリストの場合、CLI はそのモデル固有の既定値を使用します。 --reasoning-effortまたは使用可能な場合はモデル ピッカーを使用してレベルを選択します。

モデル機能の制限

次のフィールドは、 models[].capabilities.limits内に属しています。 すべて省略可能です。

トークンの予算を手動で設定する場合は、モデルの maxPromptTokens、 maxContextWindowTokens、および maxOutputTokens フィールドを使用します。 Discoveryでは、制限を両方の場所に保存できます。 異なる CLI 操作が 2 つの表現を読み取るため、重複する値の一貫性を保ちます。 CLI で管理されるローカル サーバーの場合、実測されたコンテキスト制限値が構成された値よりも優先される場合があります。

トークン数と画像サイズには負以外の整数を使用し、画像数には正の整数を使用します。 トークン数と画像数は、4294967295から0の範囲内に収まる必要があります。 画像のサイズは、トークンではなくバイト単位で測定されます。

モデルシステムメッセージ

models[].systemMessage は、汎用サブエージェントを含め、CLI がこのモデルの標準プロンプトを作成するときに使用されるシステム命令を制御します。 これらのパスでは、セッション全体のシステム メッセージ構成よりも優先されます。 これは、選択したカスタム エージェントまたは特殊なサブエージェントの指示に代わるものではありません。

追加の指示のみが必要な場合は、"mode": "append" をお勧めします。 組み込みの命令を置き換えたり削除したりすると、CLI のツールの使用やその他の予期される動作が変わる可能性があります。 systemMessageに設定するのではなく、nullを省略して標準命令を保持します。

モードに一覧表示されているフィールドのみが許可されます。 たとえば、sectionsを設定せずに"mode": "customize"を追加すると、構成エラーが発生します。

代替コンテンツでは、使用可能な場合、{{copilot:memories}} により CLI のメモリ命令とコンテキストが挿入されます。

システムメッセージのセクション

customize モードでは、models[].systemMessage.sectionsはセクション名をオブジェクトにマップします。 各オブジェクトは、actionを指定し、必要に応じて、contentを指定します。 たとえば、models[].systemMessage.sections.tone はトーン セクションを変更します。

使用可能な操作は次のとおりです。

transform アクションは、保存された JSON 構成ではなく、アプリケーション コールバックを必要とするため、providers.jsonではサポートされていません。

sectionsでは、次のセクションまたはグループ名をキーとして使用します。

個々のセクションの変更は、グループの変更前に適用されます。 グループ置換は、個別にカスタマイズしたセクションを含め、すべてのメンバー セクションを置き換えます。

システムメッセージのコンテンツブロック

replace モードでは、models[].systemMessage.contentBlocksはプレーンなcontent文字列の代わりに置換命令を提供します。 構成形式で必要なため、content はそのまま残してください。 すべてのブロックには content 文字列が必要です。

モデルメタデータ

models[].metadata は、値として任意の有効な JSON 値を取れるオブジェクトです。 これは説明データであり、API 要求パラメーターや資格情報を指定する方法ではありません。 メタデータを手動で追加する必要はありません。

モデル検出では、次の文字列フィールドを保存できます。 既存の検出値はそのままにします。

プロバイダー構成の例

この例では、既存の Ollama サーバーに接続し、モデルの機能とシステム命令がどのように入れ子になっているかを示します。 qwen3:8bがインストールされていることを前提としています。 トークンの制限は予算の例であり、モデルの最大容量を示すものではありません。 サーバーで構成されているコンテキストに合わせて調整してください。

{
  "providers": [
    {
      "name": "local",
      "type": "openai",
      "baseUrl": "http://127.0.0.1:11434/v1",
      "modelProvider": "ollama"
    }
  ],
  "models": [
    {
      "id": "qwen3:8b",
      "provider": "local",
      "name": "Qwen 3 8B",
      "maxPromptTokens": 6144,
      "maxContextWindowTokens": 8192,
      "maxOutputTokens": 2048,
      "capabilities": {
        "supports": {
          "vision": false,
          "toolCalls": true
        }
      },
      "systemMessage": {
        "mode": "customize",
        "sections": {
          "tone": {
            "action": "append",
            "content": "\nUse concise explanations."
          }
        }
      }
    }
  ]
}

{
  "providers": [
    {
      "name": "local",
      "type": "openai",
      "baseUrl": "http://127.0.0.1:11434/v1",
      "modelProvider": "ollama"
    }
  ],
  "models": [
    {
      "id": "qwen3:8b",
      "provider": "local",
      "name": "Qwen 3 8B",
      "maxPromptTokens": 6144,
      "maxContextWindowTokens": 8192,
      "maxOutputTokens": 2048,
      "capabilities": {
        "supports": {
          "vision": false,
          "toolCalls": true
        }
      },
      "systemMessage": {
        "mode": "customize",
        "sections": {
          "tone": {
            "action": "append",
            "content": "\nUse concise explanations."
          }
        }
      }
    }
  ]
}

CLI を再起動した後、copilot --model local/qwen3:8b または /model ピッカーを使用してこのモデルを選択してください。 いずれかの配列にオブジェクトを追加して、追加のプロバイダーとモデルを構成します。

agents/

個人用カスタム エージェント定義を .agent.md ファイルとしてここに格納します。 このディレクトリに配置されたエージェントは、すべてのセッションで使用できます。 個人エージェントとプロジェクト レベルのエージェントが同じ ID を持っている場合 (たとえば、両方の最上位ファイルに reviewer.agent.md名前が付けられている場合)、個人用エージェントが優先されます。 省略可能な name frontmatter フィールドは重複除去を制御しないため、同じ name で ID が異なるエージェントは両方とも読み込まれます。

詳細については、「GitHub Copilot CLI のカスタムエージェントの作成と使用」を参照してください。

skills/

個人のカスタム スキル定義をここに格納します。 各スキルは、 SKILL.md ファイル ( ~/.copilot/skills/my-skill/SKILL.md など) を含むサブディレクトリに存在します。 個人のスキルはすべてのセッションで利用できます。 Projectレベルのスキルは、同じ名前を共有する場合、個人のスキルよりも優先されます。

詳細については、「エージェント スキルの追加 GitHub Copilot CLI」を参照してください。

hooks/

ユーザー レベルのフック スクリプトをここに格納します。 これらのフックは、すべてのセッションに適用されます。 ~/.copilot/settings.json キーを使用して、ユーザー構成ファイル (hooks) でフックをインラインで定義することもできます。 リポジトリ レベルのフック ( .github/hooks/) は、ユーザー レベルのフックと共に読み込まれます。

詳細については、「GitHub Copilot CLI でフックを使用する」を参照してください。

extensions/

ユーザー レベルの拡張ファイルをここに格納します。 このディレクトリ内の拡張機能は、セッション間で使用できます。

このディレクトリにファイルを手動で作成するか、拡張機能をスキャフォールディングしてから、生成されたファイルを編集できます。

ファイルを自動的に管理する

次の項目は CLI によって管理されます。 通常、手動で編集しないでください。

config.json

認証データ、インストールされているプラグイン メタデータ、その他のランタイム情報など、CLI によって自動的に管理される内部アプリケーションの状態を格納します。 通常、このファイルを編集する必要はありません。

permissions-config.json

保存したツールとディレクトリのアクセス許可の決定をプロジェクトの場所別に格納します。 ツールを承認するか、現在の場所のディレクトリへのアクセスを許可すると、CLI によって決定がここに記録されるため、同じリポジトリまたはディレクトリに再度プロンプトが表示されることはありません。

ファイルの場所

Copilot CLI は、構成ディレクトリからファイルを解決します。

CLI では、この順序で最初に適用できる構成ディレクトリのみが使用されます。 優先順位の低い場所から permissions-config.json も読み込まれません。

--config-dir オプションは従来のオプションです。 構成ディレクトリを変更する必要がある場合は、 COPILOT_HOME を優先します。

Windowsでは、既定のファイルは通常次のようになります。

C:\Users\YOUR-USER\.copilot\permissions-config.json

以前のビルドでは、 permissions-configという名前の拡張子のないファイルが使用されています。 permissions-config.jsonが存在しないが、拡張子のないファイルが存在する場合、CLI はレガシ ファイルを引き続き受け入れられます。 新しい編集には permissions-config.json を使用します。

以前の XDG ベースの構成場所は、~/.copilotが設定されていない場合、起動時にCOPILOT_HOMEに移行されます。

位置キー

最上位レベルの locations オブジェクトは、絶対パスによってキーが設定されます。

• Git リポジトリの場合は、アクセス許可のスコープに使用される Git ルートを使用します。
• リンクされたワークツリーはメイン リポジトリのルートを参照するため、メインワークツリーと権限を共有します。
• サブモジュールは、独自の作業ディレクトリを使用します。
• Git リポジトリにないディレクトリの場合は、正規化された現在の作業ディレクトリを使用します。

キーは、 Copilot CLI が実行されている場所と一致する必要があります。 キーが一致しない場合、保存された承認は適用されません。

CLI は、セッションの開始時とアクティブな作業ディレクトリの変更時に、一致する場所の承認を読み込みます。

Schema

ファイルには JSON オブジェクトが含まれている必要があります。

permissions-config.json では、拒否ルール、"ask" ルール、既定のモード、URL ルール、ツール のフィルター処理、またはリポジトリローカル共有ポリシーはサポートされていません。 これらの動作では、 --deny-tool、 --available-tools、 --excluded-tools、 --allow-url、 --deny-urlなどのコマンド ライン オプションを使用します。 保存された URL ルールは、settings.jsonではなく、permissions-config.jsonに格納されます。

不明なフィールドはスキーマの一部ではありません。 CLI では無視され、後で書き込みによって削除される場合があります。

承認の種類

tool_approvalsの各項目は、次のいずれかのオブジェクトである必要があります。

MCP 承認の場合、 serverName は構成された MCP サーバー名と正確に一致する必要があります。 サニタイズされたツール名プレフィックスではなく、MCP 構成の生サーバー名を使用します。

シェルコマンドの照合

permissions-config.json では、正規表現や一般的な glob パターンはサポートされていません。 文字列値は文字どおりに一致します。ただし、シェル :* 値内の末尾の commandIdentifiers は、:* より前のテキスト（そのテキスト単独の場合と、その後にスペースと追加のテキストが続く場合の両方）に一致します。 プレーンな * には特別な意味がないため、 git* は git statusと一致しません。

ディレクトリ マッチング

allowed_directories エントリを使用すると、 Copilot CLI は個別のパス プロンプトなしで、これらのディレクトリ内のパスにアクセスできます。 ツール操作自体は承認されません。 たとえば、許可されたディレクトリ内のファイルを編集するには、引き続き write の承認が必要な場合があります。

各 allowed_directories エントリは、絶対、空でない、アクセス可能なディレクトリである必要があります。 CLI は、パスを比較する前にシンボリック リンクを解決し、UNC ネットワーク パスは拡張長ローカル パスでない限り許可せず、Windows では大文字と小文字を区別せずにパスを比較し、その他のプラットフォームでは大文字と小文字を区別してパスを比較します。 エントリを適用できない場合、CLI は警告をログに記録し、そのエントリをスキップします。

Examples

すべての Git サブコマンドを許可し、追加のローカル ディレクトリにアクセスします。

{
  "locations": {
    "C:\\src\\my-repo": {
      "tool_approvals": [
        {
          "kind": "commands",
          "commandIdentifiers": ["git:*"]
        }
      ],
      "allowed_directories": ["C:\\src\\shared-docs"]
    }
  }
}

{
  "locations": {
    "C:\\src\\my-repo": {
      "tool_approvals": [
        {
          "kind": "commands",
          "commandIdentifiers": ["git:*"]
        }
      ],
      "allowed_directories": ["C:\\src\\shared-docs"]
    }
  }
}

ファイルの書き込み前に確認しながら、選択したコマンドを許可します。

{
  "locations": {
    "/Users/YOUR-USER/src/my-repo": {
      "tool_approvals": [
        {
          "kind": "commands",
          "commandIdentifiers": [
            "git status",
            "git diff",
            "git log",
            "npm test",
            "npm run build"
          ]
        }
      ]
    }
  }
}

{
  "locations": {
    "/Users/YOUR-USER/src/my-repo": {
      "tool_approvals": [
        {
          "kind": "commands",
          "commandIdentifiers": [
            "git status",
            "git diff",
            "git log",
            "npm test",
            "npm run build"
          ]
        }
      ]
    }
  }
}

リポジトリのファイル書き込みと 1 つの MCP サーバーを承認します。

{
  "locations": {
    "/home/YOUR-USER/src/my-repo": {
      "tool_approvals": [
        {
          "kind": "write"
        },
        {
          "kind": "mcp",
          "serverName": "github-mcp-server",
          "toolName": null
        }
      ]
    }
  }
}

{
  "locations": {
    "/home/YOUR-USER/src/my-repo": {
      "tool_approvals": [
        {
          "kind": "write"
        },
        {
          "kind": "mcp",
          "serverName": "github-mcp-server",
          "toolName": null
        }
      ]
    }
  }
}

1つのMCPツール、メモリへの書き込み、拡張機能の権限へのアクセスを承認する:

{
  "locations": {
    "C:\\src\\my-repo": {
      "tool_approvals": [
        {
          "kind": "mcp",
          "serverName": "github-mcp-server",
          "toolName": "search_code"
        },
        {
          "kind": "memory"
        },
        {
          "kind": "extension-permission-access",
          "extensionName": "my-extension"
        }
      ]
    }
  }
}

{
  "locations": {
    "C:\\src\\my-repo": {
      "tool_approvals": [
        {
          "kind": "mcp",
          "serverName": "github-mcp-server",
          "toolName": "search_code"
        },
        {
          "kind": "memory"
        },
        {
          "kind": "extension-permission-access",
          "extensionName": "my-extension"
        }
      ]
    }
  }
}

session-state/

サブディレクトリ内のセッション ID 別に整理されたセッション履歴データが含まれています。 各セッション ディレクトリには、イベント ログ (events.jsonl) とワークスペース成果物 (プラン、チェックポイント、追跡されたファイル) が格納されます。 このデータにより、セッションの再開 (--resume または --continue) が有効になります。

このディレクトリからファイルを削除すると、ローカル コピーのみが削除されます。 GitHub アカウントにセッションを同期した場合、同期されたデータは個別に保存され、ローカル ファイルの削除の影響を受けません。 同期されたセッションは、 GitHub.comから削除したり非表示にしたりできます。 詳細については、「GitHub Copilot のセッション データについて」を参照してください。

command-history-state/

対話型インターフェイスの逆引き検索 (Ctrl+R) と履歴ナビゲーションに使用されるコマンド履歴データが含まれています。 このディレクトリは自動的に管理されるため、編集しないでください。

session-store.db

チェックポイントのインデックス作成や検索などのセッション間データに CLI によって使用される SQLite データベース。 このファイルは自動的に管理され、編集しないでください。

このファイルを削除した場合は、 /chronicle reindex コマンドを使用してリビルドできます。 インデックスを再作成すると、セッション データもアカウントに同期されます。

logs/

CLI セッションのログ ファイルが含まれています。 各セッションでは、 process-{timestamp}-{pid}.logという名前のログ ファイルが作成されます。 これらのファイルは、問題のデバッグに役立ちます。

CLI では、 logs/extensions/の下に拡張機能固有のログを作成することもできます。

これは、ユーザーが作成した拡張機能コードを格納する ~/.copilot/extensions/とは別です。

installed-plugins/

インストールしたプラグインのファイルが含まれています。 マーケットプレースからインストールされたプラグインは、 installed-plugins/{marketplace-name}/{plugin-name}/の下に格納されます。 直接インストールされたプラグインは、 installed-plugins/_direct/の下に格納されます。 このディレクトリを直接編集するのではなく、 copilot plugin コマンドを使用してプラグインを管理します。

詳細については、「GitHub Copilot CLI プラグイン リファレンス」を参照してください。

plugin-data/

マーケットプレースとプラグイン名別に整理された、インストールされているプラグインの永続的なデータが含まれています。 このデータはプラグイン自体によって管理されるため、手動で編集することはできません。

ide/

IDE 統合のロック ファイルと状態が含まれます (たとえば、 Copilot CLI が Visual Studio Code に接続する場合)。 このディレクトリは自動的に管理されます。

mcp-oauth-config/

キーチェーンベースのストレージが使用できない場合の MCP OAuth トークン、登録、PKCE フォールバック ファイルが含まれます。 このディレクトリは自動的に管理されます。

mcp-secrets/

キーチェーンベースのストレージが使用できない場合のフォールバック ファイル ストレージと MCP シークレット プレースホルダーのインデックスが含まれます。 このディレクトリは自動的に管理されます。

構成ディレクトリの場所の変更

既定の ~/.copilot 場所をオーバーライドするには、 COPILOT_HOME 環境変数を使用するディレクトリのパスに設定します。

export COPILOT_HOME=/path/to/my/copilot-config

export COPILOT_HOME=/path/to/my/copilot-config

注意すべき事項

• COPILOT_HOME は、 ~/.copilot パス全体を置き換えます。 設定する値は、構成ファイルとサブディレクトリに使用するディレクトリへの完全なパスである必要があります。

• ディレクトリを変更すると、既存の構成、セッション履歴、インストールされているプラグイン、保存されたアクセス許可が新しい場所に見つかりません。 ~/.copilotの内容を保存する場合は、新しい場所にコピーまたは移動します。

• キャッシュ ディレクトリ (Marketplace キャッシュ、自動更新パッケージ、およびその他のエフェメラル データに使用) はプラットフォームの規則に従い、COPILOT_HOMEの影響を受けません。 これは次の場所にあります。

  • macOS: ~/Library/Caches/copilot
  • Linux: $XDG_CACHE_HOME/copilot または ~/.cache/copilot
  • Windows:%LOCALAPPDATA%/copilot

  キャッシュ ディレクトリを個別にオーバーライドするには、 COPILOT_CACHE_HOME設定します。

安全に削除できる内容

構成ファイルの設定

設定は次の順序で適用されます (後でオーバーライドします)。

1. 組み込みの既定値
2. モバイルデバイス管理（MDM）の管理対象設定
3. ユーザー設定 (~/.copilot/settings.json)
4. リポジトリの設定 (.github/copilot/settings.json)
5. ローカル設定 (.github/copilot/settings.local.json)
6. 環境変数
7. コマンド ライン フラグ

MDM マネージド設定は起動時に読み込まれ、ポリシー ベースラインとしてユーザー設定とマージされます。 ほとんどのキーでは、ユーザー設定がそのベースラインをオーバーライドできます。 permissions.disableBypassPermissionsMode の場合、"disable" の MDM 値が常に優先されます。 マネージド sandbox 設定も例外です。 オーバーライドできるのではなく、各管理対象の sandbox 値は、緩和できない下限を設定します。 独自の設定の方が許容度が高い場合は、マネージド値が優先されます。 sandbox.failIfUnavailable設定は、管理者のみが設定できます。 詳細については、「 MDM の管理設定」を参照してください。

CLI では、リポジトリ設定の共有クロスツール サブセット (.claude/settings.json、.claude/settings.local.json、companyAnnouncements、disableAllHooks、enabledPluginsなど) のextraKnownMarketplacesとhooksも読み取ります。

リポジトリの既定値は任意です。enabledPlugins エントリをリポジトリローカル設定で false に設定して、リポジトリの既定値をオーバーライドします。 マネージドの必須またはブロックされたプラグイン エントリが常に優先されます。 「GitHub Copilot CLI のプラグインの検索とインストール」を参照してください。

ユーザー設定 (~/.copilot/settings.json)

これらの設定は、すべてのセッションとリポジトリに適用されます。 /settingsスラッシュ コマンドを使用して対話型ダイアログを実行したり、特定のスラッシュ コマンドを使用して個々の値を更新したり、このファイルを直接編集したりできます。

/sandboxダイアログでは、Git 認証、**** 認証、マスクされた環境変数が専用の gh タブの下にグループ化され、現在のサンドボックス構成が格納されている settings.json パスが表示されます。 [ ファイルシステム ] タブでは、構成済みのパスの一覧がアクセス許可 (たとえば、 2 read/write, 1 read-only) ごとに ユーザー設定パス 行の下で要約されます。 その行の Enter キーを押して完全なリストを開きます。このリストは、 Esc キーを押すまでカーソルとタブ バーを引き継ぎます。構成されたパスは、 ./相対または ~短縮形式ではなく、絶対パスとして表示されます。 パスを追加するときに「 ~/path 」と入力しても、ホーム ディレクトリに展開されます。 [/sandbox] ダイアログで Ctrl+Eキーを押して保留中の変更を保存し、エディター (COPILOT_EDITOR、VISUAL、またはEDITOR) でsettings.jsonを開き、/settingsで同じショートカットに一致させます。 ファイルを編集して保存すると、ダイアログによってディスクからその状態が再読み込みされます。

ホスト規則と sandbox.userPolicy.network.proxy は、組み込みのローカル プロキシを使用します。 両方が構成されている場合、ローカル プロキシは、アップストリーム プロキシにトラフィックを転送する前にホスト 規則を適用します。 アップストリームの資格情報は、サンドボックス化された子プロセスの外部にとどまります。 送信アクセスがオフの場合、ホストルールとプロキシ設定は非アクティブになります。

サンドボックス設定でプロキシが設定されていない場合、ローカル プロキシは、ホスト上でこの順序で HTTPS_PROXY、HTTP_PROXY、ALL_PROXY のうち最初に空でない環境変数からアップストリーム プロキシを選択します。 socks5 と http:// プロキシのみがサポートされ、https:// はサポートされません。

ホストの NO_PROXY に一致する宛先は、この継承されたアップストリーム プロキシだけをバイパスします。 サンドボックスのローカル プロキシは引き続きこれらの接続を処理し、そのホスト規則を適用します。 サンドボックス設定で構成されたプロキシは、NO_PROXYを無視します。

macOS と Linux では、サンドボックスによって直接接続が制限されるため、プログラムはプロキシを回避できません。 Windowsでは、サンドボックスはプロキシ設定に従うプログラムに依存します。 その結果、Windowsのプロキシ設定を無視するプログラムは直接接続し、ホストルールを回避できます。 Windowsプロキシとホスト ルールでは、サポートされているホストとallowLocalNetwork: trueも必要です。これはプライベート ネットワーク アクセスを許可します。 Linux では、プロキシ設定では、 [::] デュアルスタック ワイルドカード以外の IPv6 アドレス リテラルが拒否されます。 IPv4 エンドポイントまたは IPv4 サポートのホスト名を使用します。

サンドボックス設定は、ユーザー レベルまたは企業管理です。 これらはリポジトリでオーバーライドできません。 構成手順とネットワークの制限事項については、 ローカル サンドボックス設定の構成 を参照してください。

サンドボックスはMicrosoft eXecution Container (MXC)によって実現されており、プラットフォーム固有の分離バックエンドを提供します。 Copilot CLIでは、macOS では Seatbelt、Linux では Bubblewrap、Windowsでは ProcessContainer が使用されます。

リポジトリの設定 (.github/copilot/settings.json)

リポジトリの設定は、リポジトリ内で作業するすべてのユーザーに適用されます。 これらはリポジトリにコミットされ、コラボレーターと共有されます。

リポジトリ レベルでは、次の表に示すキーのみがサポートされています。 その他のキー (ユーザー構成ファイルで有効なキーを含む) は、暗黙的に無視されます。 サポートされている各キーには、オーバーライドがフェールクローズかつ安全な状態に保たれるようにする方向性を持つマージポリシーがあります。

model、 effortLevel、および contextTier オーバーライドは、作業ディレクトリが 信頼されている場合にのみ適用されます。

リポジトリの enabledPlugins を介してのみ有効になっているプラグインは、そのリポジトリにスコープが設定されます。これは、宣言するリポジトリに自動インストールおよびアクティブ化されますが、グローバルに無効のままであるため、関連のないプロジェクトではアクティブ化されません。 リポジトリまたはプラグインを無効にするリポジトリを離れると、MCP サーバーが破棄され、セッションのエージェントとスキルが非アクティブ化されます。

リポジトリ レベルのモデルの許可リスト (.github/allowed_models.txt)

現在の作業ディレクトリのリポジトリ ルート (またはリポジトリの外部にある作業ディレクトリ自体) から解決された、 .github/allowed_models.txtのプレーンテキスト許可リストでリポジトリが使用できる組み込みモデルを制限します。

各行は、モデル ID に一致する glob パターン、または構成済みまたは要求されたモデルが許可されていない場合に使用するモデルに名前を付ける fallback: ディレクティブです。

# .github/allowed_models.txt
fallback: gpt-6-astra
gpt-6-astra
gpt-6-sol
claude-sonnet-*

否定パターン (!pattern) はサポートされていません。フォールバック モデルは、(glob ではなく) 正確な ID である必要があり、フォールバック モデル自体が構成された glob のいずれかに一致している必要があります。 Copilot CLI /cdでポリシーを再評価し、実行前にエラーが発生した無効なファイルを拒否します。

許可リストは、 Copilotの組み込みモデルのみを管理します。 Bring Your Own API Keys (BYOK) メソッドを使用して追加されたカスタム モデルを除外することはできません。 BYOK モデルは、構成するパターンに関係なく一覧表示され、選択可能なままであり、 fallback: ディレクティブは適用されません。 詳細については、「エンタープライズでのGitHub Copilotのカスタム モデルの有効化」および「組織内のGitHub Copilotのカスタム モデルを有効にする」を参照してください。

ローカル設定 (.github/copilot/settings.local.json)

コミットすべきでない個人用オーバーライドの .github/copilot/settings.local.json をリポジトリに作成します。 このファイルを .gitignoreに追加します。

ローカル構成ファイルは、リポジトリ構成ファイル (.github/copilot/settings.json) と同じスキーマを使用し、そのスキーマよりも優先されます。

MDM で管理される設定

IT 管理者は、ユーザーごとの構成を必要とするのではなく、モバイル デバイス管理 (MDM) の管理対象設定を使用してベースライン ポリシーをプッシュできます。 これらの設定では、サポートされているキーのデバイス レベルの既定値が適用され、ユーザー設定の前に読み込まれます。

マネージド設定は、対話型、 -p、 --acp、 --ahp-host、 --serverなど、すべてのセッション ホスティング モードに均一に適用されるため、エンタープライズ MCP、アクセス許可、プラグイン ポリシーは、別のエントリ ポイントを介してセッションを開始することによってバイパスできません。

Copilot CLI また、MDM に加えて、起動時にサーバーで管理される設定も読み込まれます。 デバイス管理（MDM）設定とサーバー管理設定は、キーごとに適用されます。MDM で設定されたキーでは MDM の値が優先され、MDM で未設定のキーはサーバーの値で補われます。 これにより、組織は MDM ( permissions など) を使用してポリシーを設定しながら、サーバーから他の管理対象の既定値 ( model など) を受け取ります。

実行時間の長いセッションでは、1 時間ごとに管理設定の再フェッチと再適用が行われるので、ポリシーの変更 (たとえば、 permissions.disableBypassPermissionsModeを有効にする組織) は、セッションを再起動せずに有効になります。

MDM 管理対象設定の提供元

Copilot CLI は、プラットフォーム固有の MDM またはファイル ベースの場所からマネージド設定を読み取ります。

ファイル形式

ファイル ベースのマネージド設定を JSON として書き込みます。

{
    "model": "auto",
    "permissions": {
        "disableBypassPermissionsMode": "disable"
    }
}

サポートされているキー

MDM 管理設定では、次のキーのみがサポートされます。

sandbox.learningModeはWindows専用であり、ネイティブ MDM (Intune やレジストリなど) 経由でのみ設定できます。managed-settings.json ファイルの値は無視されます。 拒否キャプチャを使用するホストで、既定のレコードおよび拒否モードではなく、レコードアンド許可モードでサンドボックス シェル コマンドを開始するように "allow" に設定し、各ファイルシステムまたはプロセスのアクセスを記録し、拒否するのではなく許可します (ネットワーク ポリシーは引き続き適用されます)。 これにより、管理者は、コーホートをロックダウンする前に、コーホートのコマンドに何が必要かを観察できます。これはコンテインメント モードではありません。 状態行には sandbox relaxed が表示され、シェル呼び出しは適用されている間 (sandbox relaxed) を表示します。 deny値 (既定値) またはキーを削除すると、通常の強制サンドボックスにコーホートが返され、マネージド チャネルからのdenyは常にallowよりも優先されます。 ユーザー設定と SDK ホストでは、このキーを設定できません。

マネージド アクセス許可ルール

マネージド permissions キーの下にdeny、ask、およびallowルール リストを追加して、すべてのユーザーにアクセス許可ポリシーを適用します。 これは、 permissions.disableBypassPermissionsMode が設定されているかどうかに関係なく機能します。

{
    "permissions": {
        "deny": ["Shell(rm -rf *)", "Domain(*.evil.example)"],
        "ask": ["Shell(git push *)"],
        "allow": ["Read(**)"]
    }
}

ルールは、固定の優先順位を持つマネージド ソース間で結合されます。拒否は常に優先され、次に要求され、許可されます。 deny ルールに一致すると、 allow ルールも一致する場合でも要求がブロックされます。 deny と ask は、すべてのマネージド ソース (サーバー、MDM) で共用化されます。 allow では、allow リストを宣言するすべてのソースでその操作が許可されている必要があります。つまり、和集合ではなく積集合として扱われます。 deny、ask、または allow のいずれかが設定されている場合、それらのいずれにも一致しない操作は、暗黙にフォールスルーするのではなく、既定で ask になります。

Edit(...) および Write(...) ルールは、組み込みのファイル ツールよりも多くの場合に適用されます。 また、シェル コマンドによって直接書き込まれたファイルについても説明します。 Copilot CLI は、これらの書き込みの固定セットを認識します。 Bash 出力リダイレクト (>、 >>、 >|、 &>、 &>>)、PowerShell 出力リダイレクト (>、 >>、 *>、 *>>)、および少数のインプレース sed 編集 (sed -i または --in-place、BSD フォームの -i '' と -I '') について説明します。 Copilot CLIコマンドからターゲット ファイルを処理できる場合は、一致するdenyルールによって書き込みがブロックされ、一致するaskルールによって最初にプロンプトが表示されます。 これは、 Shell(*) のような広範なルールでコマンドが許可される場合でも適用されます。 パスが変数から取得された場合など、ターゲット ファイルを事前に処理できない場合があります。 その場合、これらのパスルールは適用されず、代わりに通常のシェルコマンドルールによってコマンドがチェックされます。

ドメイン境界 (limitTo)

マネージド limitTo キーの下に、deny、ask、およびallowと共にpermissions配列を追加して、クローズド ワールド ドメイン許可リストを適用します。

{
    "permissions": {
        "limitTo": ["github.com", "*.github.com"]
    }
}

Domain(...)では、limitToエントリのみがサポートされます。 リスト外のドメインに対するエージェント ネットワーク要求は、プロンプトなしで拒否され、ユーザー ルール、保存された承認、およびすべて許可モードでも、この許可範囲を広げることはできません。 シェル要求で検出された URL は、Domain 要求として扱われ、境界条件も満たす必要があります。 limitTo 自体では、shell、read、または write の操作を制限しません。

空の limitTo リストは、すべてのドメイン要求を拒否します。 無効なリストまたは無効なエントリは、管理ポリシーの残りの部分を破棄するのではなく、空のリスト (および構成エラーとして報告) として扱われます。

deny 引き続き limitToよりも優先されます。 ask と allow は、既に境界内にある要求のみを絞り込みます。 allowと同様に、limitToはマネージド ソース全体にわたる交差集合です。limitTo リストを宣言するすべてのマネージド ソースは、そのリクエストを受け入れなければなりません。

管理対象 MCP サーバーの許可/拒否リスト

管理者は、エンタープライズ MCP 許可リストに関係なく、MDM で管理された設定を使用して MCP サーバーを直接管理できます。

マネージド設定ソースで allowedMcpServers または deniedMcpServers を設定します。

{
    "allowedMcpServers": [
        { "serverUrl": "https://mcp.example.com/*" },
        { "serverCommand": ["npx", "-y", "@example/mcp-server"] }
    ],
    "deniedMcpServers": [
        { "serverName": "untrusted-server" }
    ]
}

各エントリは、次のいずれかのマッチャーによってサーバーを識別します。

準則：

• 信頼されたファースト パーティ サーバー (組み込みの GitHub MCP サーバーなど) は、常に両方のリストから除外されます。
• allowedMcpServersの設定を解除するでは、既定以外のすべてのサーバーが許可されます。空の配列は、それらすべてをブロックします (deny-all)。
• 設定解除または空の deniedMcpServers は何もブロックしません。
• 拒否は常に優先されます。 deniedMcpServers に一致するサーバーは、 allowedMcpServersにも一致する場合でもブロックされます。
• リモート サーバーの場合、一致はserverUrlエントリから取得する必要があります。serverName``serverUrlエントリが存在しない場合にのみカウントされます。 stdio サーバーの場合、一致はserverCommandエントリから取得する必要があります。serverName``serverCommandエントリが存在しない場合にのみカウントされます。

詳細については、次を参照してください。

• GitHub Copilot CLI
• GITHUB COPILOT CLI コマンド リファレンス
• GitHub Copilot CLI プログラムリファレンス
• GitHub Copilot CLI プラグイン リファレンス
• GitHub Copilotフックリファレンス