受管文件与命令限制

文件访问和命令执行由不同机制约束。对敏感文件施加 deny_read 后，还应按操作系统确认 shell 子进程是否受相同限制；不要只用直接文件工具测试。

禁止读取路径

requirements.toml 可用绝对路径或以用户目录为基准的 ~ 路径，也支持 glob：

[permissions.filesystem]
deny_read = [
  "/**/*.env",
  "~/.ssh",
]

以 ./ 开头的相对路径不允许。用户配置不能削弱这些要求。有 deny-read requirements 时，本地运行时拒绝 full-access permissions，维持可实施限制的只读或工作区沙箱。

原生 Windows 的 managed deny_read 只应用于直接文件工具，shell 子进程读取不使用这条沙箱规则。需要按实际读取路径单独验证。

强制命令规则

requirements 中的 prefix_rules 与普通 .rules 合并，最严格决定优先。与普通规则不同，这里的 decision 必填，且只能是 prompt 或 forbidden，不能是 allow。

[rules]
prefix_rules = [
  { pattern = [{ token = "git" }, { any_of = ["push", "commit"] }], decision = "prompt", justification = "Require review before mutating history." },
]

这个示例要求对应 Git 命令审批。规则如何匹配 token、包装 shell 和多条命令，应结合Rules的检查流程测试，不能由单个命令前缀推断所有等价动作都被拦截。

迁移旧审批配置

显式 approval_policy = "untrusted" 已退役，应从用户、项目、profile 和托管默认值中移除。交互只读工作可使用 on-request 加管理员允许的只读权限。

若需要项目不受信任时派生的严格审批，官方要求省略显式 approval_policy，在用户配置的项目条目中设置 trust_level="untrusted"，并让 allowed_approval_policies 保留 untrusted。该方式同时关闭项目本地配置；显式 on-request 会覆盖派生策略。允许列表里的 untrusted 不表示可以恢复已退役的显式写法。