为 Codex CLI 提供安全可控的仓库感知编码能力，涵盖审批策略、沙箱选择、MCP 边界及 PR 就绪验证工作流
说明：
## 核心用法
Codex 技能将 OpenAI Codex CLI 从通用聊天助手转变为可安全操作的编码代理。其核心设计围绕**显式边界**展开：通过 `~/codex/` 记忆目录持久化仓库配置、审批策略和安全默认设置，避免每次会话重复协商信任边界。
**六大执行模式**：
– **交互式 CLI**：探索性仓库工作，适合理解代码结构
– **`codex exec`**：有界非交互式执行，适合自动化脚本
– **`codex review`**：审优先模式，强制人工检查变更
– **resume/fork**：会话恢复与分支，避免重复上下文重建
– **MCP 辅助**：经用户明确批准的模型上下文协议服务器
– **Cloud/OSS 本地**：云端任务或 `–oss` 本地开源模型路由
**关键预检流程**：运行任何写操作前必须锁定五项事实——目标仓库、当前目录、工作区脏状态、所需权限、预期验证方式。此设计防止”目录错误”这一最常见陷阱。
**沙箱层级**：
| 模式 | 适用场景 | 风险等级 |
|——|———|———|
| read-only | 检查、规划、低信任探索 | 低 |
| workspace-write | 标准本地编码 | 中 |
| full-access/dangerous-bypass | 特殊情况需显式用户意图 | 高 |
## 显著优点
1. **防御性架构**：将”安全默认”内嵌于工作流——`–dangerously-bypass-approvals-and-sandbox` 被明确标记为反模式而非便捷选项
2. **状态持久化**：`~/codex/` 结构将仓库约定、MCP 批准清单、事件恢复模式跨会话保留
3. **可审计轨迹**：强制”以检查结束”——每次运行需报告变更内容、验证结果、失败项及残留风险
4. **MCP 边界清晰**：可用≠批准，每个 MCP 服务器需经用户显式授权并记录允许的数据访问范围
5. **多表面统一**：覆盖 CLI、exec、review、resume、MCP、app-server、cloud、本地 OSS 提供商，但**不模糊其风险差异**
## 潜在缺点与局限
– **依赖 OpenAI 服务**：核心执行需 `api.openai.com`，无法完全离线运行（除非使用 `–oss` 本地模式）
– **初始配置负担**：首次使用需运行 `setup.md` 并配置 `~/codex/` 记忆结构，对一次性任务可能过度
– **审批摩擦**：严格的安全边界可能降低”快速原型”场景的流畅度
– **MCP 生态风险**：用户批准的 MCP 服务器若本身存在漏洞，技能无法二次隔离
– **平台限制**：二进制依赖 `codex`，Windows/Darwin/Linux 支持但需独立安装
## 适合人群
– **团队 Tech Lead**：需为团队建立 Codex 使用规范，防止成员使用危险绕过模式
– **安全敏感型开发者**：在受监管环境或私有代码库中操作，需明确数据流向和审批记录
– **多仓库维护者**：频繁切换项目，需要每仓库的约定记忆（测试命令、入口点、爆炸半径笔记）
– **自动化工作流构建者**：使用 `codex exec` 集成 CI/CD，需可复现、可审查的编码步骤
## 常规风险
| 风险场景 | 缓解设计 |
|———|———|
| 目录错误导致误编辑 | 强制预检五项事实，dirty tree 时区分用户/代理变更 |
| 沙箱绕过常态化 | `–dangerously-bypass` 需显式用户意图，不隐藏于便捷选项后 |
| MCP 服务器过度授权 | `mcp-notes.md` 强制记录批准范围及拒绝理由 |
| 云输出盲目应用 | 要求本地审查 diff 后再应用 |
| 会话中断后重复/不一致工作 | `resume`/`fork` 机制，推荐中断时留下 crisp checkpoint |
| 凭证泄露 | 不从任意文件抓取 token，`OPENAI_API_KEY` 需显式流程 |
## 外部依赖
– **必要**：`codex` 二进制、OpenAI API 访问（或 `–oss` 本地替代）
– **可选**：`git`（仓库操作）、`rg`（ripgrep 搜索）
– **用户批准**：特定 MCP 服务器主机、Codex Cloud 端点
会员专属
