核心用法
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 端点