> [!left-bubble] ![[chappy.webp]] **[[チャッピー]]** > [[ChatGPT]]の[[Deep Research (ChatGPT)|Deep Research]] によって生成されています。 ## エグゼクティブサマリー 結論として、**`--allow-tool` と `--deny-tool` を「環境変数」や「ユーザー設定ファイル(例:`~/.copilot/config.json`)」で直接・永続的に指定する公式手段は、少なくとも公式ドキュメント上は確認できません**(2026-02-23 時点の公開資料ベース)。ツール実行の自動承認は、基本的に **(a) 起動時の CLI フラグ**(`--allow-tool` / `--deny-tool` / `--allow-all-tools` など)か、**(b) 対話セッションでの承認フロー(Allow once / Always allow)**で管理する、という整理になっています。citeturn11view0turn16search1turn4search2 一方で、**環境変数でできるのは「全ツール自動許可」相当(`COPILOT_ALLOW_ALL`)の“粗い”設定**であり、`--allow-tool` / `--deny-tool` 相当の細粒度指定は(少なくとも公式の CLI リファレンス記載としては)見当たりません。citeturn1view2turn4search2 また「設定ファイルによる制御」については、ユーザー設定の `config.json` は主に信頼ディレクトリ等の設定用途として案内されており、**`allow/deny tool` の永続ルールを config キーで設定する説明はありません**。ただし、**リポジトリ配下のフック設定(`.github/hooks/*.json`)を使うと、`preToolUse` で“実行前に拒否する”ポリシーを JSON+スクリプトで実装でき**、実務上は deny 相当のガードレールを構成可能です(ただしこれは「`--deny-tool` を config で指定」ではなく、「ツール実行そのものをフックでブロック」)。citeturn21view0 ## 結論と根拠 公式ドキュメントが示す「ツール許可(tool permissions)」の制御は、次の 2 系統に整理されています。 第一に、**起動時フラグでの明示的な許可・拒否**です。`--allow-all-tools`(全許可)、`--allow-tool`(特定許可)、`--deny-tool`(特定拒否)があり、さらに `--deny-tool` が優先されることが明記されています。citeturn11view0turn13view4 第二に、**対話実行中にツール実行の都度承認する方式**です。初回実行時に「今回だけ」「セッション中のみ承認」「拒否」のような選択肢が提示される設計で、セキュリティ上の注意点(意図しない破壊的操作等)も併記されています。citeturn11view0turn13view4 この枠組みの中で、環境変数について公式に確認できるのは、少なくとも **`COPILOT_ALLOW_ALL=true` が `--allow-all-tools` 相当として機能する**という点です(CLI リファレンスに “env: COPILOT_ALLOW_ALL” が明記)。一方、`--allow-tool` / `--deny-tool` を同様に環境変数で与える公式キー名は、公開ドキュメント上では確認できません。citeturn1view2turn4search2 設定ファイルについても、公式ドキュメントでユーザーが編集対象として案内されるのは主に `~/.copilot/config.json`(例:`trusted_folders`)であり、**同ファイルに `allow-tool` / `deny-tool` 相当の永続ルールを置けるという記述はありません**(許可は CLI フラグ or セッション内承認として説明)。citeturn11view0turn15search0 「永続的に許可したツールをリセットする」ための `/reset-allowed-tools` が存在し、対話的に “Always allow”(将来セッションでも許可)する仕組み自体は示唆されていますが、**それがどのファイルに・どのキー名で保存されるか**、および**ユーザーが編集してよい安定 API か**は、公式資料からは明確ではありません(少なくとも設定キーとしてのドキュメント化は見当たりません)。citeturn16search1turn10search2 ## 設定手段の対応状況と具体例 ### `--allow-tool` / `--deny-tool` の“正確な指定形式”と関連キー名 公式ドキュメント上で、`--allow-tool` / `--deny-tool` は「どの種類のツールを対象にするか」を引数で表現します(例:`shell(...)`、`write`、`MCP server(...)`)。citeturn11view4turn13view4 加えて、実際の `copilot help permissions` 出力(公式リポジトリ Issue に貼られたもの)では、**許可/拒否パターンの“kind(argument)”形式と、`:*` による prefix マッチ、`url(...)` などの kind**が具体的に整理されています(特に headless 実行時に重要)。citeturn14view0 代表的なパターン(引用ではなく要約): - `shell(COMMAND)`:シェルコマンド。`:*` で prefix マッチ(例:`shell(git:*)`)。citeturn14view0turn11view4 - `write`:シェル以外のファイル変更系ツールの許可/拒否。citeturn14view0turn11view4 - `MCP_SERVER_NAME(tool_name?)`:特定 MCP サーバー(と任意でその配下ツール)を許可/拒否。citeturn11view4turn14view0 - `url(domain-or-url?)`:URL アクセス要求の許可/拒否(web-fetch や一部ネットワーク系コマンドに適用される旨)。citeturn14view0turn11view4 また、**ツールの“見える/見えない”を制御する `--available-tools` / `--excluded-tools` と、実行前確認をスキップする `--allow-tool` / `--deny-tool` は別概念**で、前者で不可視化(利用不能化)されたツールは後者で許可しても露出しない、という整理が `copilot help permissions` 側で明示されています。citeturn14view0turn11view0 ### 小さな比較表(env var / config file / なし) | 方法 | `--allow-tool` / `--deny-tool` を“直接”設定できるか | 再現手順(最小) | 長所 | 短所 | |---|---|---|---|---| | 環境変数 | **原則できない**(確認できるのは `COPILOT_ALLOW_ALL` による全許可相当のみ)citeturn1view2 | `COPILOT_ALLOW_ALL=true copilot -p "..."`(= `--allow-all-tools` 相当)citeturn1view2 | CI 等で“全自動”にしやすい | きめ細かい deny/allow を表現できない(少なくとも公式記載なし)citeturn1view2 | | 設定ファイル(ユーザー) `~/.copilot/config.json` | **公式には不明/非推奨**:信頼ディレクトリ等の編集は案内されるが、allow/deny tool の永続キーは説明されていないciteturn11view0turn15search0 | `~/.copilot/config.json` を編集して `trusted_folders` を更新citeturn11view0 | ディレクトリ信頼などは永続化できる | tool allow/deny の永続設定としては根拠不足(キー名・仕様が公開されていない)citeturn11view0 | | 設定ファイル(リポジトリ)フック `.github/hooks/copilot-cli-policy.json` | **“代替として可能”**:`preToolUse` で実行前に deny を実装できる(ただしフラグの設定ではなくブロック/監査)citeturn21view0 | `.github/hooks/copilot-cli-policy.json` 作成 → `preToolUse` スクリプトで deny ロジックciteturn21view0 | 監査ログ+強制 deny を repo 単位で配布可能 | 実装コスト(スクリプト/運用)、フックの仕様理解が必要citeturn21view0 | | なし(毎回 CLI フラグ) | **できる**(これが公式に案内される手段)citeturn11view0turn13view4 | `copilot -p "..." --allow-tool ... --deny-tool ...`citeturn11view0 | 明示的で再現性が高い | 毎回付ける手間(ワークアラウンドが欲しくなる)citeturn13view4 | ### 具体例(コピペ可能) #### 例:`git` は広く許可しつつ `git push` だけ拒否(deny が優先) ```bash copilot -p "ブランチ整理の提案をして、不要なブランチを消して" \ --allow-tool 'shell(git:*)' \ --deny-tool 'shell(git push)' ``` deny が allow より優先される挙動自体は公式に明記されています。citeturn11view0turn13view4 #### 例:ファイル編集(`write`)を無確認で許可 ```bash copilot -p "README を整形して、見出し構造も改善して" \ --allow-tool 'write' ``` `write` が許可/拒否の対象になり得ることは公式ドキュメントに記載があります。citeturn11view4turn13view4 #### 例:非対話(headless)で全ツール自動許可(環境変数) ```bash COPILOT_ALLOW_ALL=true \ copilot -p "直近コミットを要約して" ``` `COPILOT_ALLOW_ALL` が `--allow-all-tools` 相当になる旨は CLI リファレンスに記載されています。citeturn1view2 ## 設定ファイルの場所・優先順位と mermaid 図 ### 主要なファイル配置(公式に明記される範囲) ユーザー設定ファイル `config.json` は、デフォルトでホーム配下の `.copilot` にあり、OS により例示パスが示されています(macOS/Linux: `~/.copilot/config.json`、Windows: `$HOME\.copilot\config.json`)。citeturn11view0 また、設定ディレクトリは CLI フラグ `--config-dir` で指定でき、デフォルトが `~/.copilot` と明記されています。citeturn4search2turn9view0 さらに、`XDG_CONFIG_HOME` を設定すると設定場所が変わる旨が公式ドキュメントに記載されています(少なくとも `config.json` / `mcp-config.json` の保存場所の観点)。citeturn11view0turn15search0 ### 重要な“優先順位”の論点(確実に言えること/曖昧なこと) 確実に言えること: - **`--deny-tool` は、`--allow-all-tools` と `--allow-tool` より優先**されます。citeturn11view0turn13view4 - **`--available-tools` / `--excluded-tools` による「ツール可視性の制限」は別レイヤ**で、許可フラグは「確認を省略する」だけで、フィルタされたツールを再度“見える化”しない(`copilot help permissions` の説明)。citeturn14view0 - 設定ディレクトリは `--config-dir` で上書き可能であり、デフォルト値が明記されています。citeturn4search2turn9view0 曖昧(=公式に明文化されていない)点: - `--config-dir` と `XDG_CONFIG_HOME` が同時に与えられた場合の厳密な優先順位は、公式ドキュメント本文からは直接確認できません(通常は CLI フラグが優先されるのが自然ですが、ここは推測になります)。citeturn11view0turn4search2 - 対話セッションの “Always allow(将来も許可)” がどこにどう保存され、起動フラグとどう競合するか(例えばフラグが常に勝つのか等)は、少なくとも公開ドキュメントだけでは仕様が断定できません。citeturn16search1turn10search2 ### mermaid:概念的な優先順位フロー(公開情報ベース) ```mermaid flowchart TD A[起動] --> B{設定ディレクトリ} B -->|--config-dir 指定| B1[指定パスを使用] B -->|XDG_CONFIG_HOME 設定| B2[XDG_CONFIG_HOME 配下を使用] B -->|どちらも無| B3[デフォルト ~/.copilot] A --> C{ツール可視性フィルタ} C -->|--available-tools / --excluded-tools| C1[モデルが見えるツール集合を制限] C -->|未指定| C2[デフォルトの見えるツール集合] A --> D{自動承認(確認スキップ)ルール} D -->|--deny-tool| D1[deny が最優先] D -->|--allow-all-tools または COPILOT_ALLOW_ALL| D2[全ツール確認スキップ] D -->|--allow-tool| D3[指定ツールのみ確認スキップ] D -->|未指定| D4[対話承認プロンプトへ] ``` ※ `XDG_CONFIG_HOME` と `--config-dir` の厳密な優先順位は本文明記がないため、この図では“概念”として分岐を描いています。citeturn11view0turn4search2 ## バージョンによる挙動差分 `--allow-tool` / `--deny-tool` まわりで、公開ソースから“差分として特定できる”ものは以下です(バージョン上限は未指定のため open-ended)。 - **0.0.329(2025-09-29)**:`--allow-tool` / `--deny-tool` の `shell(...)` ルールで **glob matching(例:`shell(npm run test:*)`)**が追加された旨が changelog に記載されています。つまり、少なくともこの版以降は `:*` を用いた prefix/グロブ的表現が重要になります。citeturn9view0 - **0.0.381(2026-01-13)**:`--allow-all` および `--yolo`(全許可ショートカット)の追加が changelog で確認できます。`--allow-all-tools` / `--allow-all-paths` / `--allow-all-urls` をまとめた性格のため、権限設計の“入口”が変わっています。citeturn9view0turn11view4 - **0.0.382(2026-01-14)**:`--config-dir` フラグが追加された旨が changelog に記載されています。設定ファイルの配置戦略(個人/CI/一時ディレクトリ等)に影響します。citeturn9view0turn4search2 なお、2026-02-21 時点でリポジトリ上の “Latest” が 0.0.414 と表示されており、挙動は継続的に更新されています(public preview)。citeturn5view0turn11view0 ## セキュリティ含意と実務的ワークアラウンド ### セキュリティ含意(公式が明記するリスク) 公式ドキュメントは、`--allow-all-tools` のような自動承認オプションを使うと、**事前レビューなしにコマンド実行やファイル変更が進み得る**ため、意図しない破壊的操作・データ損失・セキュリティ問題のリスクが上がる、と明示しています。citeturn13view4turn11view4 そのリスク緩和策として、**VM・コンテナ等の隔離環境での実行**や、権限・ネットワーク制限の強い環境に閉じ込めることが推奨されています。citeturn13view4 ### 実務ワークアラウンド(“環境変数/設定ファイルで直接できない”前提での代替) ワークアラウンドは大きく 2 系統です。 第一に、**ラッパー(関数/スクリプト/エイリアス)で毎回フラグを付与**する方法です。公式の “programmatic interface” の説明でも、スクリプトでオプションを生成して `copilot` にパイプする例が示されています。citeturn12view0 (例:bash 関数として `copilot_safe()` を定義し、常に `--deny-tool 'shell(rm:*)'` 等を付ける) 第二に、**フックで“実行前強制 deny”+監査ログ**を組み立てる方法です。GitHub Docs のチュートリアルでは、`.github/hooks/copilot-cli-policy.json` を作り、`preToolUse` で危険パターン(例:`sudo`、破壊的操作、download-and-execute)をブロックし、さらにログ・告知バナー等を構成する手順が公式に提供されています。citeturn21view0 これは「`--deny-tool` を config に書く」そのものではありませんが、**組織ポリシーを repo スコープで強制する**という意味では、allow/deny 管理の現実解になり得ます。citeturn21view0 最後に、**「ツール確認スキップ」と「ツール自体の不可視化」を分ける**のが安全設計上重要です。`--available-tools` / `--excluded-tools` で“そもそも使えない”状態に落とすほうが、`--deny-tool` より硬い制御になる局面があります(help permissions の説明)。citeturn14view0turn11view0 ## 参照した主要ソース ```text https://docs.github.com/en/copilot/how-tos/copilot-cli/set-up-copilot-cli/configure-copilot-cli https://docs.github.com/en/copilot/reference/cli-command-reference https://docs.github.com/en/copilot/concepts/agents/copilot-cli/about-copilot-cli https://docs.github.com/en/copilot/how-tos/copilot-cli/cli-best-practices https://docs.github.com/en/copilot/tutorials/copilot-cli-hooks https://github.com/github/copilot-cli https://raw.githubusercontent.com/github/copilot-cli/main/changelog.md https://github.com/github/copilot-cli/issues/1482 https://github.com/github/copilot-cli/issues/307 ```