policy-and-managed-settings

添加企业策略

根据受管控行为的实现位置选择策略目标，而不是根据提出需求的团队来选择。Copilot Agent 行为的大多数控制应归属于 SDK/运行时，而非 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]

请遵循对应的指南：

• SDK/运行时管理的设置
• VS Code 配置策略
• 扩展提供的设置
• 运行时/编辑器分离控制
• 1.133 之前的权限策略迁移
• Agent Host 策略支持与迁移就绪情况

更改策略分类、已应用要求的谓词或管理员迁移就绪情况诊断时，请使用支持与维护指南。无论是审查现有控制还是添加新控制，都适用此指南。

一般规则：

• 对运行时内部执行的行为，运行时强制执行具有权威性。
• 不要在 VS Code 中重复实现运行时解析器、匹配器或安全决策。
• 只有由编辑器/工作台负责的行为才适合使用 VS Code 策略。
• 新的 Copilot 企业控制应采用共享的托管设置/SDK 模型。
• VS Code 设置到托管设置的桥接仅用于兼容旧版设置。不要为了桥接而添加新的 VS Code 设置；应直接在托管设置/SDK 契约中定义由运行时负责的新控制。桥接本身始终启用；不要为其重新引入兼容性门控。
• 每次更改 VS Code 或扩展策略后，都要运行 npm run export-policy-data。切勿手动编辑 build/lib/policies/policyData.jsonc。

说明被策略禁用的功能

用户应能理解，为何发行说明或文档中介绍的功能不可用。优先让相关选项保持可见但处于禁用状态，并显示标准的公文包托管策略标识、本地化说明和可访问的后续步骤，而不是静默地将其筛除。请遵循共享设计指南和设置/模型/权限选择器示例。

使用权威的策略来源信息，区分被禁止的选项、不受支持的功能、功能门控和待处理状态。将界面呈现与授权分开：将 Assisted 或 Allow All 显示为禁用状态，绝不能让被禁止的值重新进入运行时允许的枚举，也不能绕过创建/恢复/写入验证。测试策略刷新/移除、键盘和指针激活、过期菜单以及独立的帮助链接；保留显式隐藏 AI 的行为。

已弃用和历史渠道

某些策略渠道仍受支持，以服务现有控制，但不再接受新属性：

• GitHub 令牌/帐户策略数据（AccountPolicyService 使用的 IPolicyData 字段）不再用于新控制。不要从 GitHub 令牌添加新的授权或策略属性。现有字段为保持兼容性而保留。
• 新的 Copilot 企业控制使用托管设置和运行时/SDK 强制执行。
• 1.133 之前的权限策略转换是范围有限的迁移，不是可复用的渠道。

其他渠道弃用时，请在此处记录其边界，并在相关目标指南中保留实现细节。

参考资料：

• GitHub Copilot 托管设置
• 本地策略测试

请让这些指南聚焦于契约。记录贡献者的决策和行为不变量；对于可能发生偏移的实现内容，请链接到源代码，而不是复制内容。

应以可执行源代码和测试为准，而不是规划文档。