| name | policy-and-managed-settings |
| description | Use whenever adding, modifying, or reviewing any Copilot, agent, LLM, AI, tool, permission, sandbox, MCP, model, telemetry, feature-gate, setting, configuration, or enterprise control—especially anything an organization or administrator may need to manage. Start here to decide whether it belongs in runtime managed settings, a typed SDK contract, VS Code configuration policy, extension policy, or a split implementation. Run on every new Copilot/agent/LLM control and ANY change that adds a `policy:` field. |
Adding an Enterprise Policy
Choose the policy destination by where the governed behavior is implemented, not by
which team requested it. Most controls for Copilot agent behavior belong in the
SDK/runtime rather than VS Code.
flowchart TD
A[Enterprise control] --> P{Existing permission policy<br/>introduced before VS Code 1.133.0?}
P -->|Yes| L[Pre-1.133 compatibility migration]
P -->|No| B{Where is the governed behavior implemented?}
B -->|Copilot runtime, tools, MCP,<br/>sandbox, or agent loop| R[SDK/runtime managed setting]
B -->|VS Code editor or workbench| V[VS Code configuration policy]
B -->|Extension-provided setting| E[Extension policy]
B -->|Independent runtime and editor behavior| M[Split runtime/editor control]
Follow the matching guide:
General rules:
- Runtime enforcement is authoritative for behavior executed inside the runtime.
- Do not duplicate a runtime parser, matcher, or security decision in VS Code.
- A VS Code policy is appropriate only for editor/workbench-owned behavior.
- New Copilot enterprise controls should target the shared managed-settings/SDK model.
