多项目配置与 profiles 管理

不同仓库的风险等级、依赖与网络需求不同，用一套全局配置"一刀切"要么过宽、要么束手束脚。合理做法是按项目组织配置：共享一份安全基线，再为差异最小化地补充项目偏好。官方安全示例中，可把已知开发目录纳入沙箱可写根，并按团队、用户组或环境测试不同配置。本节讲组织方法；profiles 的具体实现命令与文件位置以当前官方文档为准。

一、为什么要分项目配置

全局统一的问题	分项目配置的收益
为便利给所有项目放宽写权限，高风险仓库也被暴露	按仓库最小授权，只读调研项目不给写权限
网络与审批策略无法区分，噪声多或效率低	按任务类型匹配审批与网络边界
团队成员配置漂移，行为不一致	共享基线 + 受控差异，结果可预期、可审计
实验性改动污染主工作区	隔离实验配置与独立目录，失败可丢弃

二、分项目配置的组织维度

1. 按目录边界：为项目目录设定明确的可写范围。官方示例中 sandbox_workspace_write.writable_roots 可把已知开发目录列入可写根（示例键名，以官方文档为准），其余位置保持只读。
2. 按风险等级：只读调研类、常规开发类、受控自动化类分别匹配不同沙箱与审批姿态，风险越高越保守。
3. 按运行环境：本地交互、隔离实验、CI 流水线使用不同配置；CI 采用更严格的最小权限（详见第 10 章）。
4. 按团队角色：管理员下发统一基线，成员只在允许范围内补充个人偏好，差异集中、便于审查。

三、可复用的配置片段思路

片段类别	作用	维护要点
安全基线片段	统一默认沙箱姿态、凭据存储与禁止项	全项目共享、版本化管理、变更需评审
审批偏好片段	常规任务减少打断、高风险仍需确认	不放宽强制项，只调整低风险操作节奏
网络白名单片段	限定依赖与检索所需来源	最小开放、定期复核过期域名
项目目录片段	限定可写根与受保护路径	新增目录显式登记，不使用宽泛通配

四、切换与维护纪律

• 先备份再改动：每次调整保留上一版，便于回退到已知良好状态。
• 小步变更：一次只调整一个维度（如只改某项目的可写根），验证稳定后再改下一项。
• 团队配置入库管理：共享基线随仓库或统一配置库版本化，成员同步同一版本。
• 记录适用理由：为每套配置标注适用项目、风险等级与理由，避免配置堆积无人维护。
• 防止复制漂移：公共内容引用同一基线，项目差异单独存放，不整份复制后各自改乱。

五、FAQ

问题	处理建议
profiles 具体怎么定义、命令是什么	以当前官方文档与 codex --help 为准；本节先掌握"按项目/风险/环境分层组织"的方法，不写死未核实语法。
能否给 CI 单独一套更严配置	应当如此：流水线使用独立最小权限配置，不沿用本地宽松默认（见第 10 章）。
多套配置取值冲突怎么办	回到第 9 章第一节的优先级原则：强制与更安全取值优先，冲突项不允许个人放宽。
如何避免全局可写范围过宽	默认只读，按需为具体项目目录显式追加可写根，不使用覆盖整个用户目录的宽泛写法。

六、动手练习

• 练习：为两个不同风险的项目各写一份"配置要点清单"（风险等级、沙箱姿态、可写范围、网络需求、审批节奏），标出共享基线项与项目差异项；先以清单形式落地，待官方 profiles 语法确认后再转成实际配置。