Codex常用命令速查大全：CLI、Desktop与任务恢复完整指南
Codex 的常用操作分为 CLI 命令和 Desktop 快捷入口两套：CLI 适合脚本、CI 和精细控制，Desktop 适合项目、文件、浏览器和长任务协作。高效使用的关键不是记住几十个参数，而是先确认工作区状态，再让 Codex 修改，最后用测试和 Git 差异验收。本文同时覆盖两种形态；CLI 参数以本机 codex --help 为准，Desktop 快捷键以“Settings > Keyboard Shortcuts”为准。
常用命令总览
CLI 与 Desktop：命令对应什么操作
Desktop 的项目可以关联一个或多个本地文件夹；主文件夹决定默认工作目录和 AGENTS.md、Skills、config.toml 的自动发现位置。次级文件夹可读写，但不会自动发现这些项目级配置。
Desktop 常用命令与快捷键
Desktop 没有 CLI 那样的终端子命令，主要通过命令菜单、斜杠命令和快捷键完成操作。按 ⌘⇧P 或 ⌘K 打开命令菜单，按 / 打开斜杠命令列表。
常用斜杠命令包括：
/status：查看聊天 ID、上下文使用量和速率限制。/model：切换当前聊天模型。/reasoning：调整推理力度。/plan：进入多步骤计划模式。/review：审查未提交改动或与基线分支比较。/project：选择项目。/worktree：在新的 Git worktree 中运行任务。/mcp：查看 MCP 连接状态。/compact：压缩当前聊天上下文。/fork：从当前聊天创建新的本地聊天或 worktree。
macOS 高频快捷键：⌘O 打开文件夹，⌘P 搜索文件，⌘⇧E 切换文件树，⌃⇧G 打开 Review，⌘T 打开内置浏览器，⌘⇧B 切换浏览器面板，⌘⌥A 跳到下一个需要处理的 Codex 聊天，⌘⌥C 复制会话 ID，⌘⇧C 复制工作目录。
Windows/Linux 将 ⌘ 换成 Ctrl 或 Super 的对应组合；可在“Settings > Keyboard Shortcuts”搜索命令并自定义按键。
--full-auto 只是减少确认步骤，并不代表模型更准确。真实仓库应优先使用默认确认模式或临时分支。
1. 安装后先验证环境
codex --version
codex --help
codex login进入仓库后先保存初始状态：
cd /path/to/your-repository
git status --short
codex/path/to/your-repository 是占位路径。不要把 API Key 写入 Shell 历史、项目文件或公开日志。
2. 三种启动模式
只读分析适合陌生仓库和安全审计：
codex --sandbox read-only默认模式会在执行命令或写文件前请求确认：
codex批量测试或临时分支可使用全自动模式：
git switch -c codex/task-name
codex --full-auto执行高风险命令前检查 pwd、目标文件和影响范围；不要在生产目录直接使用 --full-auto。
3. 如何描述一次任务
任务提示应包含目标文件、约束、验证命令和完成标准：
请修复 src/parser.ts 的空输入异常，只修改 parser 和对应测试；完成后运行 npm test -- parser，并总结 git diff。要求 Codex 修改后运行最小相关测试，而不是只回复“已完成”。如果任务涉及多个模块，先让它输出计划，再分阶段执行。
4. 会话恢复与长任务
终端断开或任务需要稍后继续时：
codex resume恢复前查看工作区：
git status --short
git diff --stat恢复后先让 Codex总结已完成步骤、剩余步骤和失败命令，再继续。无法恢复时，把 git diff、日志和剩余目标交给新会话。
5. Git 差异与测试验收
git status --short
git diff --stat
git diff -- src/ tests/常见项目验证命令：
npm test
npm run lint
npm run build这些是 Node 项目示例；Python、Rust 等项目应使用仓库已有的 pytest、cargo test 或其他脚本。绿色测试只证明已覆盖的断言通过，不代表需求完整实现。
6. 配置与诊断
遇到模型、Provider 或配置不生效，检查常见配置文件：
ls -l ~/.codex/config.toml
sed -n '1,220p' ~/.codex/config.toml
codex --help分享日志前脱敏 API Key。若命令失败，先确认目录和运行时：
pwd
which node
node --version
which python3
python3 --version不要只复制最后一行错误，完整上下文通常包含真正原因。
7. 高频痛点的命令组合
改了太多文件
git status --short
git diff --stat
git diff --name-only停止会话，确认文件清单，再要求只保留直接相关改动。不要直接运行 git clean -fd，它可能删除未跟踪文件。
做到一半停止
git status --short
git diff --stat
codex resume恢复后先输出状态摘要和下一步计划。
测试通过但功能不对
git diff
npm test
npm run lint补充能复现真实用户流程的测试，并人工检查关键页面或接口。
命令执行失败
先用 pwd、which 和版本命令确认环境，再把完整日志交给 Codex。不要让模型通过盲目升级依赖来“修复”环境错误。
8. 推荐工作流
git status --short保存初始状态。使用
codex --sandbox read-only阅读仓库并给出计划。默认交互模式下限定目标文件和验证命令。
修改后运行最小测试，再运行完整测试或构建。
用
git diff --stat和git diff检查范围、敏感文件和依赖变化。人工 Review 后提交 Git；长任务中断则用
codex resume。
9. Desktop 项目工作流
用
⌘O打开代码目录，或在 Projects 中添加本地项目并指定主文件夹。新建 Codex 聊天，先让模型只读了解目录、
AGENTS.md和现有测试。需要多个仓库时，在项目设置中添加次级文件夹；涉及 Git 提交和 worktree 的操作仍以主仓库为准。
通过
/plan生成计划，通过/model和/reasoning选择当前任务配置。需要浏览器、电脑操作或文件预览时，从 Desktop 的工具面板打开对应能力；每次授权前检查目标站点和文件。
修改完成后用
⌃⇧G打开 Review，检查文件清单和差异，再运行内置终端中的测试命令。长任务可关闭窗口后从项目 Chats 重新打开；需要并行方案时使用
/fork或/worktree，不要让多个聊天同时改同一个工作目录。
Desktop 的优势是把项目、聊天、文件、浏览器和 Review 放在同一个工作区；CLI 的优势是可脚本化、可在 CI 中运行。两者可以使用同一个 Git 仓库，但不要把“聊天恢复”和“Git 回滚”混为一谈：恢复聊天只找回上下文，不能自动撤销已经写入磁盘的改动。
FAQ
Q1：codex --full-auto 可以用于生产仓库吗？ 不建议。它适合可回滚的临时分支；生产仓库应使用默认确认模式并限制目录和命令范围。
Q2：为什么 codex resume 找不到任务？ 可能是登录身份、工作目录或 CLI 版本变化。先运行 codex --help，确认用户和仓库路径；无法恢复时用 Git 差异和日志重建上下文。
Q3：修改后至少运行什么？ 至少运行相关单元测试并检查 git diff；前端或构建项目再补充 lint、类型检查和 build。
Q4：Desktop 和 CLI 能共用一个项目吗？ 可以共用同一个 Git 仓库和项目文件，但 Desktop 通过本地项目管理文件夹，CLI 以启动目录或 --cd 指定工作区；两边同时修改时应使用不同 worktree。
Q5：如何避免 Codex 读取密钥？ 不把密钥放在任务目录或提示词中，使用环境变量和忽略文件，并在分享日志前脱敏。
结论
Codex 常用命令的核心不是自动化程度越高越好，而是让任务在可观察、可回滚的边界内推进。CLI 用 codex --sandbox read-only、codex --full-auto 和 codex resume 处理脚本化任务；Desktop 用项目、斜杠命令、Review 和快捷键管理文件与长任务。两者都应与 git status、git diff 和测试命令配合，最终以本机帮助和官方文档为准。
参考资料：
