VS Code Copilotの承認、リスクバッジは自動化条件にならない

誰におすすめ

VS CodeのGitHub Copilotエージェントモードを日常の実装に使っていて、コマンドごとの承認ダイアログに集中を切られていると感じている個人開発者・少人数チームの開発者向けです。全許可のAutopilotのような設定には自分のリポジトリや認証情報を預けるのが怖くて踏み切れない一方、「低リスクだけ自動で通す」設定を探して見つけられていない人を想定しています。

何をすべきか

VS Codeの承認ダイアログに出る「低リスク」のような表示は、chat.tools.terminal.autoApproveという自動承認の設定そのものには入力されません。VS Code公式ドキュメントによれば、この設定が自動承認の可否を決める材料は、ユーザーが書いたallow/denyの正規表現ルールがコマンドのサブコマンド（既定）、またはmatchCommandLine: trueを指定した場合は行全体に一致するかどうかだけです。バッジの判定がこの一致判定に使われているという記述は、公式ドキュメントのどこにもありません。

バッジのような都度のリスク判定を行っているのは、2026年7月22日リリースのVS Code 1.130で加わった別の機能です。これは「Assisted permissions」というオプトイン設定で、ツール呼び出しのたびに言語モデル自身がリスクを評価し、自動実行するか承認を求めるかを決めます。ただしVS Code自身のドキュメントは、この機能について「モデルは判断を誤り、危険な可能性のあるツール呼び出しを承認することがある」「あなたの判断の代わりにはならない」と明記しています。

つまり読者が探している「バッジが緑の時だけ自動化する」設定は存在せず、代わりに読者自身が静的な許可リストを書く作業に置き換わります。今日決めるべきは、(a) 何も変えず都度承認を続けるか、(b) chat.tools.terminal.autoApproveに自分でallow/denyルールを書くか、(c) Assisted permissionsのような広い自動承認に倒すか、の三択です。(b)を取る場合は、書いたルール1行が実際にはコマンド名ではなく引数を含む文字列全体を承認対象にしている点を踏まえて線を引く必要があります。

VS Code公式のセキュリティ文書は、ルールベースの自動承認自体についても「ベストエフォートのコマンド解析」であり、シェルのエイリアス・引用符の連結・複雑なシェル構文に既知の限界があると認め、より強い保護としてAgent sandboxingを推奨しています。ただしこのsandboxingはmacOSとLinux（WSL2含む）にのみ提供されており、ネイティブのWindowsは対象外です。これはVS Code公式のセキュリティ文書と、The Register（2026年3月11日）の報道の両方で確認できています。

注意点

chat.tools.terminal.autoApproveとAssisted permissionsの挙動に関する説明は、いずれもVS Code公式ドキュメント・リリースノートという単一系統の情報源に基づいており、独立した第三者による検証は確認できていません。Assisted permissionsは2026年7月22日リリースからまだ日が浅く、将来のリリースで挙動が変わる可能性があります。ルールベースの自動承認の限界（シェルのエイリアス、引用符の連結、複雑なシェル構文）はベンダー自身の記述であり、公開された実証コードでの独立検証は確認できていません。Agent sandboxingのネイティブWindows対応について、公開されている計画は確認できていません。