【GitHub Copilot】開発環境で AutoApprove を安全に使う方法

未分類
2026.04.24

要点

■settings.json

  • “chat.permissions.default”: “autoApprove“, // 新セッションを Bypass Approvals で開始
    • “chat.tools.terminal.autoApprove”: true,　 //Terminalコマンド自動承認
    • “chat.tools.edits.autoApprove”: true,       //ファイル編集自動承認
    • “chat.tools.command.autoApprove”: true,  //VSCode自体の操作の自動承認
  • “chat.tools.global.autoApprove”: false, // 全ツール無差別 auto-approve は使わず
  • “chat.agent.sandbox.enabled”: true, //terminal commandをsandboxで実行(影響範囲限定)
  • “chat.agent.sandbox.FileSystem.linux”　// Linux / macOS 用の file system 制御(ｵﾌﾟｼｮﾝ)
  • ＋
  • “github.copilot.chat.additionalReadAccessFolders” //WorkSpace外ReadOnly
  • “chat.agent.networkFilter”: true,　//Network アクセス制限

■Linux (WSL2),Mac OK , Windows NG　

■settings.json 書き換え後は、リロード

　　　Ctrl + Shift + P
　　　Developer: Reload Window

■サンプル

settings.json sample
{
  // 新しいセッションを Bypass Approvals で開始
  "chat.permissions.default": "autoApprove", 
 
　// 全ツール無差別 auto-approve は使わない
  "chat.tools.global.autoApprove": false,

  // terminal command を sandbox 内で実行
  "chat.agent.sandbox.enabled": true,

  // Linux / macOS 用の file system 制御
  "chat.agent.sandbox.FileSystem.linux": {

    // カレントディレクトリ配下は書き込み可
    "allowWrite": ["."], 

   // この配下は書き込み禁止
    "denyWrite": [
      "./deploy/",
      "./infra/prod/",
      "./backups/"
    ],    
　　// この配下は読み取りも禁止
    "denyRead": [
      "./secrets/",
      "./.env",
      "./.env.local",
      "/home/your-user/.ssh"
    ]
  }, 
　// built-in file tools 用の sensitive file 保護
  "chat.tools.edits.autoApprove": {
    "**/.env": false,
    "**/.env.*": false,
    "**/secrets/**": false,
    "**/deploy/**": false,
    "**/infra/prod/**": false,
    "**/backups/**": false,
    "**/*.pem": false,
    "**/*.key": false
  }
}

はじめに

以前、本番 VPS 向けには、chat.tools.terminal.autoApprove で読み取り系コマンドだけを自動承認し、破壊系は必ず手動承認する構成を採用した。これは本番環境では非常に妥当で、安全側に倒した運用として有効だった。

一方で、開発環境では事情が少し違う。
調査、lint、test、軽微な修正を何度も回すため、terminal コマンドごとに approval を挟むとテンポが悪い。しかも VS Code の公式説明では、terminal の auto-approve ルールはbest-effort なコマンド解析であり、複雑な shell 構文や quote のつなぎ方などで検出をすり抜ける可能性があるとされている。

そこで開発環境では、
「危険コマンドを正規表現で全部見分ける」発想ではなく、最初から AI が触れてよい範囲を OS レベルで狭める」
というアプローチの方が筋がよい。VS Code の公式でも、高い自律性を使うなら sandboxing や container と組み合わせることが勧められている。

本記事では、この考え方に基づき、次の構成を紹介する。

  • 新しいセッションは autoApprove で開始する
  • ただし global.autoApprove は使わない
  • terminal コマンドは sandbox 内で自動承認させる
  • built-in file tools については sensitive file 保護を併用する

1. なぜ従来の terminal.autoApprove だけでは足りないのか

本番向け記事で使った方法は、chat.tools.terminal.autoApprove に正規表現を書き、ls、grep、git diff などを自動承認しつつ、rm、sudo、systemctl、git push などを拒否するものだった。これは観察専用の本番運用では理にかなっている。

ただし開発環境で「もっと自由に AutoApprove したい」と考えたとき、この方法には限界がある。
VS Code 公式では、auto-approval は approval fatigue を減らせないこと、コマンド解析には限界があること、そして quote concatenation のようなテクニックでルールをすり抜けられる可能性まで明示している。さらに file write 検出も最小限で、terminal からの書き込みを完全には把握できないとされている。

つまり、
「危険コマンドを全部 blacklist する」
よりも、
「そもそも危険な場所へ到達できないようにする」
方が、開発用の高自律運用には向いている。

2. 採用する方針

今回の方針は次のとおり。

2.1 permission level は autoApprove

chat.permissions.default は、新しい chat session の既定 permission level を設定する。autoApprove を選ぶと、新規セッションは Bypass Approvals で開始される。なお、session ごとに後から変更できる。

2.2 chat.tools.global.autoApprove は使わない

chat.tools.global.autoApprove はすべての tools を自動承認する設定で、VS Code 公式でも critical security protections を無効化する と明記されている。開発環境でも、ここを true にするのは強すぎる。

2.3 terminal は sandbox に入れる

chat.agent.sandbox.enabled を有効にすると、agent が実行する terminal commands は自動承認される代わりに、file system と network access が制限される。デフォルトでは、コマンドはファイルシステム全体を read できるが、write は current working directory とその配下に限られ、network は全ドメイン block される。さらに allowWrite、denyWrite、denyRead で絞り込める。

2.4 built-in file tools は別で守る

重要なのは、sandbox はterminal commands にだけ適用されることだ。
VS Code の built-in read / edit / write tools は sandbox の外で動き、VS Code の permission system に従う。したがって .env や secrets のようなファイルは、chat.tools.edits.autoApprove などで別途保護する必要がある。

3. 最小構成サンプル

以下が、開発環境向けの最小構成サンプルである。

{
  // 新しいセッションを Bypass Approvals で開始
  "chat.permissions.default": "autoApprove", 
 
　// 全ツール無差別 auto-approve は使わない
  "chat.tools.global.autoApprove": false,

  // terminal command を sandbox 内で実行
  "chat.agent.sandbox.enabled": true,

  // Linux / macOS 用の file system 制御
  "chat.agent.sandbox.FileSystem.linux": {

    // カレントディレクトリ配下は書き込み可
    "allowWrite": ["."], 

   // この配下は書き込み禁止
    "denyWrite": [
      "./deploy/",
      "./infra/prod/",
      "./backups/"
    ],    
　　// この配下は読み取りも禁止
    "denyRead": [
      "./secrets/",
      "./.env",
      "./.env.local",
      "/home/your-user/.ssh"
    ]
  }, 
　// built-in file tools 用の sensitive file 保護
  "chat.tools.edits.autoApprove": {
    "**/.env": false,
    "**/.env.*": false,
    "**/secrets/**": false,
    "**/deploy/**": false,
    "**/infra/prod/**": false,
    "**/backups/**": false,
    "**/*.pem": false,
    "**/*.key": false
  }
}

この構成の意味は非常に明快である。

  • セッション開始時点では autoApprove
    ただし session 単位で変更可能。
  • global autoApprove は使わない
    危険な全面開放を避ける。
  • terminal は sandbox に入る
    確認ダイアログなしで実行できるが、write と network は制限される。
  • file edit は別系統なので sensitive file を保護
    sandbox 任せにしない。

4. この設定で何が起きるか

たとえば current working directory がプロジェクトルートだとする。
その場合、agent は pytest、npm run lint、grep、ls、sed などを比較的スムーズに実行できる。sandbox 有効時は terminal commands が controlled environment で走るため、毎回 confirmation prompt を出さずに済む。

一方で、たとえば ./secrets/ を読もうとしても denyRead に引っかかる。
./deploy/ や ./infra/prod/ を書き換えようとしても denyWrite に引っかかる。さらに built-in edit tools で .env を編集しようとしても chat.tools.edits.autoApprove により manual approval が必要になる。

この設計の本質は、
「AI に危険コマンドを見分けさせる」のではなく、「危険領域に入れない」
ことである。

5. 補足1：Linux, macOS は OK / Windows はそのままでは NG

ここは誤解しやすい。
chat.agent.sandbox.enabled と chat.agent.sandbox.FileSystem.linux / .mac は、公式 settings reference では macOS and Linux only とされている。つまり、Windows ネイティブでそのまま sandbox を使う前提ではない。

VS Code の trust and safety 文書では、Windows での agent sandboxing はWSL2 を underlying platform として使うと説明されている。さらに WSL1 は非対応で、Linux/WSL2 では bubblewrap と socat などの依存が必要とされている。したがって、実務上は次の理解が正しい。

  • macOS: そのまま使いやすい
  • Linux: そのまま使いやすい
  • Windows ネイティブ: そのままでは本命ではない
  • Windows で使いたい場合: WSL2 上で使う

6. 補足2：SandBox とは何か

Sandbox とは、ここではAI が実行する terminal commands を OS レベルで隔離する仕組みである。
VS Code 公式では、approval prompt だけに頼るのではなく、file system と network access に対して OS が強制する境界を与えるものとして説明されている。sandbox 内の process とその child processes は、その境界を越えられない。

言い換えると、sandbox は
「AI を信用する仕組み」ではなく、「AI を完全には信用しなくても被害を局所化する仕組み」
である。

さらに注意点として、sandbox は万能ではない。
VS Code 公式でも、現時点では shell subprocesses のみに適用され、built-in file tools まではカバーしないと明示されている。より強い隔離が必要なら、sandbox とあわせて dev container を使うのが推奨されている。

7. どんな場面でこの設計が向くか

この設計は、次のような開発環境に向いている。

  • React / FastAPI / Python などで日常的に test や lint を回す
  • 調査コマンド、ログ確認、grep、diff を大量に使う
  • .env、秘密鍵、デプロイスクリプト、本番設定は守りたい
  • approval 連打で集中が切れるのを避けたい

逆に、本番 VPS のように
「基本は観察だけ、変更はしない」
という環境では、前回記事のような chat.tools.terminal.autoApprove 中心の conservative な設計の方が合う。

8. まとめ

本番向けの regex ベースの terminal.autoApprove は、観察専用の運用として有効である。だが、開発環境で「もっと自由に approval を減らしたい」と考えた場合、コマンドをすべて正規表現で管理するのは限界がある。VS Code 公式も、auto-approval rules の解析限界やすり抜け可能性を認めている。

そこで開発環境では、

  • chat.permissions.default = "autoApprove"
  • chat.tools.global.autoApprove = false
  • chat.agent.sandbox.enabled = true
  • chat.agent.sandbox.FileSystem.* で file system 制御
  • chat.tools.edits.autoApprove で sensitive file 保護

という構成が、自由度と安全性のバランスがよい。

要するに、
「全部を危険コマンド判定で裁く」のではなく、「AI を安全な作業場に閉じ込める」
という発想に切り替えるのがポイントである。

9.付録①追加の設定

  // ============================================================
  // ワークスペース外で、参考としてだけ読ませたい場所
  // ここは read-only
  // ============================================================
  "github.copilot.chat.additionalReadAccessFolders": [
    "/srv/ono-piano.com/reference-materials",
    "/srv/ono-piano.com/old-site",
    "/srv/ono-piano.com/design-memos"
  ],

  // ============================================================
  // ネットワーク制限
  // 必要最小限だけ許可
  // ============================================================
  "chat.agent.networkFilter": true,
  "chat.agent.allowedNetworkDomains": [
    "api.github.com",
    "raw.githubusercontent.com",
    "registry.npmjs.org",
    "pypi.org",
    "files.pythonhosted.org"
  ],
  "chat.agent.deniedNetworkDomains": [
    "*.production.example.com"
  ],

10.付録②Sandbox

■最低限 sandbox を有効にする：これだけで OK ！

{
  "chat.agent.sandbox.enabled": true
}
  • terminal コマンドは sandbox 内で実行
  • コマンドは自動承認
  • ファイルは基本 read 可能
  • 書き込みは current working directory 配下だけ
  • network は基本 block

■デフォルト挙動をカスタマイズしたいときんの追加設定

たとえば「./secrets/ は読むのも禁止」「./deploy/ は書き込み禁止」みたいにしたい場合に使います。公式にも、sandbox 有効化は chat.agent.sandbox.enabled、ファイルアクセスの調整は chat.agent.sandbox.FileSystem.linux / .mac と分けて説明されています

{
  "chat.agent.sandbox.enabled": true, 
  "chat.agent.sandbox.FileSystem.linux": {
    "allowWrite": ["."],
    "denyWrite": ["./deploy/", "./infra/prod/", "./backups/"],
    "denyRead": ["./secrets/", "./.env", "/home/your-user/.ssh"]
  }
}

コメント

タイトルとURLをコピーしました