Codex CLI 命令大全
Codex CLI 最常见的用法是进入仓库后运行 codex，然后用自然语言描述任务。随着任务增多，你还会用到恢复会话、代码审查、非交互执行、MCP 和云端任务。命令名称与参数会随版本变化，使用前先运行 codex --help，并对照官方开发者命令参考。
交互启动
cd /path/to/project
codex启动后，先告诉它目标和验收条件。常见的会话命令包括 /status 查看当前配置、/model 切换模型、/permissions 调整权限边界、/review 审查改动、/init 创建项目指导文件。斜杠命令只适用于支持它的 Codex 开发者界面，不要把它们当作普通 shell 命令。
登录和状态
codex login status
codex logoutlogin status 用于确认本地凭证状态，logout 清理本地登录信息。使用多个账户或共享电脑时，先确认当前登录身份，再执行涉及费用和项目权限的任务。
恢复会话
codex resume恢复适合继续同一个仓库、同一条任务线。恢复前先看工作区是否有新改动，避免会话上下文和当前文件状态不一致。若任务中途断线，先让 Codex 读取当前 diff 和测试结果，再继续，不要默认它记得断线前的所有动作。
代码审查
codex review审查模式用于检查未提交改动、提交或分支差异。审查提示应说明目标风险，例如数据兼容、权限边界或回归测试。审查结果是发现线索，不是自动批准；你仍需阅读代码和验证结论。
非交互执行
codex exec "总结这个仓库的测试命令"exec 适合脚本和 CI，但自动化会扩大调用频率和权限影响。先用只读任务验证输出，再设置超时、日志脱敏和失败处理。凡是会改文件、删除数据或触发外部副作用的脚本，都应有明确的工作目录和停止条件。
MCP 管理
codex mcp list
codex mcp add docs --url https://example.com/mcp
codex mcp get docs --json
codex mcp remove docs命令名称和参数以当前版本为准。添加 MCP 后先列出服务器和工具，确认认证方式及工具权限，再让模型调用。MCP 连接的是外部系统，不要把拥有写权限的生产服务当成第一次测试对象。详见Codex MCP 教程。
Cloud 与远程任务
官方 CLI 源码把 codex cloud 标为实验性入口，用于浏览 Codex Cloud 任务并在本地应用结果。具体子命令以本机帮助为准，可用性还受账户和组织配置影响。应用云端结果前先保存工作区并审查差异，应用后再运行相关验证。
常用全局选项
CLI 支持模型、沙箱、审批、目录、搜索和图片等选项，但不要从旧博客复制一串参数。执行 codex --help 查看本机版本实际支持的写法。权限相关参数与 config.toml 可能共同作用，出现行为不一致时先运行 /status 或查看配置。
命令报错的排查顺序
先确认命令属于当前版本，再确认当前目录、登录状态和参数格式。401、404、429、流式中断和工具失败要分开处理，见Codex 报错大全。如果是第三方 provider，还要检查 wire_api、模型 ID 和凭证归属。
CLI 是 Codex 使用教程中的一部分，不是全部。第一次使用建议先完成安装与登录，再阅读完整工作流。
按任务选命令，比背命令更有用
刚开始使用时，只需把操作分为几种：新任务用交互界面；继续旧任务用恢复；只需要审查时用 review；脚本里执行明确任务时用 exec；增加外部系统时管理 MCP。其余命令在遇到真实需求后再查。把所有参数堆进一个 alias，反而会让你忘记它当前用了哪种权限。
可以先从这条不会调用模型的帮助命令开始，逐项查看子命令，再决定实际执行：
codex --help
codex exec --help
codex review --help
codex mcp --help命令参数以本机帮助与官方 CLI 参考共同核对。帮助能确认当前二进制接受的语法，官方文档能说明行为和适用限制。若两者不同，先确认安装来源、版本和文档更新时间，别用添加更多参数的办法试错。
开始任务前先看当前目录
从仓库根目录启动和从子服务目录启动，可能影响工作范围、项目指导文件和依赖命令。执行 pwd 或查看 PowerShell 当前路径，确认项目不是另一个同名副本。然后运行 git status，了解已有修改；这两步属于普通开发检查，不需要消费模型请求。
在终端里启动后，可以先要求“只读说明当前目录、仓库根和准备采用的测试命令”。如果与预期不符，退出并进入正确目录，或者按本机帮助使用目录选项。不要一边让工具继续写入，一边猜它是否在正确仓库。
resume 不是撤销，review 也不会自动修好
恢复会话的用途是延续上下文，不是恢复到过去的磁盘状态。上次运行后如果你手动改过文件，恢复时应把变化说清楚，让工具重新读取。尤其是失败任务已经改了一部分文件时，不应直接重复最初要求，否则可能覆盖手工修正或重复生成结果。
代码审查的产物是问题和依据。可以要求按严重程度列出缺陷、说明触发条件并定位相关文件；如果没有发现问题，也应区分“未发现”与“代码一定正确”。想修复发现的问题，需要另给清楚的修改任务，并检查最终 diff。不要把审查模式当作隐式的全仓库重构授权。
在一个团队里，建议让作者说明验收场景，再运行审查。审查者看到的输入越接近实际变更目标，越容易判断边界。如果提示词只有“看看代码”，容易得到风格建议；若目标是阻塞发布的问题，就应该明确优先关注行为错误、数据破坏和兼容问题。
exec 的输入和输出怎样管理
非交互运行适合边界明确、可以自动验收的工作，例如总结变更、解释日志、生成待审文档草稿。脚本应为每个任务准备独立输入和输出位置，避免多个运行进程写到同一文件。输出是模型生成的材料，后续程序应检查格式和必填信息，不能直接把自然语言当作可信指令执行。
可以先在本地用一条只读任务试运行，确认凭证、目录和成本，再加入定时或 CI。任务失败时记录退出状态和相关日志，日志里不要包含完整 Key。脚本需要最大运行时间和重试上限；客户端已经重试时，外层脚本再次重复可能放大请求数量。
如果需要结构化结果，先查看本机版本的相关输出选项，再按明确的字段设计校验。不要从一段看似 JSON 的回复中随意截取字符串就触发下一步动作。涉及修改外部系统时，还需要处理重复执行和部分成功，避免重新运行把同一操作做两遍。
斜杠命令适合检查现场状态
会话中的 /status、/model 和 /permissions 能帮助你确认当前状态。它们不是“更强模型必然更正确”的开关。切换模型后，先检查任务是否仍在原有范围内，尤其是第三方模型需要额外协议和能力匹配时，界面里的显示名称不足以证明请求路径。
/init 创建的是项目指导草稿，生成后要按仓库事实修改。若已经有 AGENTS.md，先阅读再决定是否合并，避免覆盖团队约定。关于发现顺序和规则分层，见AGENTS.md 教程。
/review 之前先看当前变更范围。对于多次任务积累的 diff，可以说明哪些文件属于此次审查，哪些属于已确认的其他工作。审查结果应尽量包含具体触发条件，不能只报告“可能有问题”却没有可验证的依据。
权限参数不要藏在不透明脚本里
官方安全说明区分沙箱与审批：一个控制技术边界，另一个控制何时请求更多访问。把自动批准和完全访问写入所有启动脚本，会让后续任务继承比实际需要更多的权限。为了省去一次提示而长期放大权限，维护时很难发现。
更容易管理的做法是给日常交互、只读检查和隔离自动化分别写明使用条件。对每一种方式记录工作目录、允许网络范围、凭证来源和停止条件。只读检查不应为了沿用同一个命令模板而获得生产写入权限。
权限不足时先检查失败动作到底需要什么。某个测试需要访问临时目录，不等于整个用户目录都应可写；一个依赖安装需要联网，不等于所有后续命令都应访问任意地址。具体配置见Codex 权限与沙箱。
MCP 与模型 provider 是不同配置
codex mcp 管理的是外部工具服务；模型 provider 决定推理请求发给谁。接入一个文档 MCP，不会让模型自动改用另一家 API；更换 provider，也不会自动让原有 MCP 重新认证。排查时先分清失败发生在模型响应还是工具调用。
使用 ClawSocket 时，应先按第三方模型教程配置基础地址、环境变量和模型 ID，再运行一条小任务。只有需要外部上下文时，才另行添加 MCP。这样某一步失败时，不必同时拆掉两套设置。
给团队维护一份能复现的命令说明
团队文档可以记录已验证版本、命令用途、示例输入、预期输出和常见失败。不要只留一串匿名脚本。写明哪些示例会调用付费模型，哪些只是查看本机帮助，让新成员知道如何先做低成本检查。
升级客户端后，优先复测你实际使用的命令链，例如登录状态、只读任务、审查和一条自动化脚本。无需把所有功能都跑一遍，但任何生产流程依赖的行为，都应有能够复现的验收方式。命令参考的作用是帮助查找，团队验证记录才回答“在我们的环境里是否正常”。
三个容易选错命令的场景
任务完成后发现需求变了，可以继续同一会话说明新目标；如果要保留原结果用于比较，先保存工作区再开启新任务。恢复会话不会帮你自动创建分支，也不会撤销其他人的修改。先检查状态，再选择继续方式。
如果只想知道分支有什么风险，明确要求审查并给出证据，不必先授权修复。若随后决定修改，把批准的问题和预期行为列出来，避免工具顺便处理所有建议。风格建议和真实缺陷应分开判断。
如果脚本已经产生文件却没有正常退出，先检查输出是否完整、工作区有没有变化，再决定重试。不要用退出码之外的一句话判断全部成功，也不要把失败状态当成所有动作均未发生。恢复策略要根据实际产物设计，尤其是外部系统写入任务。
这些场景都说明，命令选择和任务边界需要一起管理。工具链越自动化，越要保留能够核对的输入、输出和验证条件。
官方资料与核对范围
以下资料用于核对产品入口、命令和配置；练习与任务模板是本文提供的操作建议，不代表已在读者设备上运行。官方源码主分支会更新，安装时请再核对本机版本。