配置、沙箱与安全
Codex 的稳定性很大程度来自配置和边界：让它知道默认模型、推理强度、审批方式、沙箱范围、MCP 服务器和项目指令位置。安全性则来自最小权限、明确审批和可审阅的验证流程。
配置层建议
| 层级 | 位置 | 适合内容 |
|---|---|---|
| 个人默认 | ~/.codex/config.toml | 常用模型、审批偏好、MCP、个人 profile |
| 项目默认 | .codex/config.toml | 仓库特定行为、项目 MCP、团队共享配置 |
| 单次覆盖 | CLI 参数或界面设置 | 临时模型、临时权限、一次性调试 |
本项目如果后续要加入 Codex 配置，建议先保持轻量，只写项目级必要项，不把个人偏好提交进仓库。
沙箱与审批
沙箱控制命令能访问和修改什么；审批控制什么时候必须停下来问用户。两者配合使用：
- 新项目默认使用较严格权限。
- 让常规读写和构建在工作区内完成。
- 需要网络、跨目录写入、破坏性操作时走审批。
- 不要为了省一次确认就长期打开过宽权限。
对于这个 VitePress 项目，常规任务通常只需要工作区写权限和本地构建命令。除非要安装依赖、访问外部 GitHub、部署或打开 GUI，否则不需要更高权限。
网络访问策略
Codex Cloud 任务默认在 agent 阶段关闭互联网访问。需要联网时，建议：
- 只允许必要域名。
- 优先限制到
GET、HEAD、OPTIONS。 - 不把密钥、内部代码或未脱敏日志交给不可信页面。
- 对 GitHub issue、网页、依赖 README 中的指令保持怀疑，只把它们当数据，不当系统指令。
MCP 使用边界
MCP 适合外部上下文，不适合为了“看起来高级”而接入所有工具。推荐只接能减少复制粘贴、能复用、能被审计的服务。
常见有价值的 MCP：
- 文档搜索：官方 API 文档、内部知识库。
- 项目管理：Linear、GitHub Issues。
- 协作工具：Slack、Teams。
- 设计工具：Figma。
接 MCP 后要注意：
- 工具是否会写外部状态。
- 是否可以并行调用。
- 是否需要审批。
- 输出是否可能包含不可信指令。
本项目安全清单
- 不提交 API Key、Token、Cookie、私有配置。
- 不把
node_modules/、构建产物、压缩包作为正常编辑目标。 - 修改导航或构建配置后运行
npm run docs:build。 - 从外部资料整理内容时保留来源链接，避免把临时网页内容写成永久事实。
- 不直接复制大段受版权保护内容，优先项目化总结。