常用命令总览

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. 安装后先验证环境

进入仓库后先保存初始状态：

/path/to/your-repository 是占位路径。不要把 API Key 写入 Shell 历史、项目文件或公开日志。

2. 三种启动模式

只读分析适合陌生仓库和安全审计：

默认模式会在执行命令或写文件前请求确认：

批量测试或临时分支可使用全自动模式：

执行高风险命令前检查 pwd、目标文件和影响范围；不要在生产目录直接使用 --full-auto。

3. 如何描述一次任务

任务提示应包含目标文件、约束、验证命令和完成标准：

要求 Codex 修改后运行最小相关测试，而不是只回复“已完成”。如果任务涉及多个模块，先让它输出计划，再分阶段执行。

4. 会话恢复与长任务

终端断开或任务需要稍后继续时：

恢复前查看工作区：

恢复后先让 Codex总结已完成步骤、剩余步骤和失败命令，再继续。无法恢复时，把 git diff、日志和剩余目标交给新会话。

5. Git 差异与测试验收

常见项目验证命令：

这些是 Node 项目示例；Python、Rust 等项目应使用仓库已有的 pytest、cargo test 或其他脚本。绿色测试只证明已覆盖的断言通过，不代表需求完整实现。

6. 配置与诊断

遇到模型、Provider 或配置不生效，检查常见配置文件：

分享日志前脱敏 API Key。若命令失败，先确认目录和运行时：

不要只复制最后一行错误，完整上下文通常包含真正原因。

7. 高频痛点的命令组合

改了太多文件

停止会话，确认文件清单，再要求只保留直接相关改动。不要直接运行 git clean -fd，它可能删除未跟踪文件。

做到一半停止

恢复后先输出状态摘要和下一步计划。

测试通过但功能不对

补充能复现真实用户流程的测试，并人工检查关键页面或接口。

命令执行失败

先用 pwd、which 和版本命令确认环境，再把完整日志交给 Codex。不要让模型通过盲目升级依赖来“修复”环境错误。

8. 推荐工作流

1. git status --short 保存初始状态。
2. 使用 codex --sandbox read-only 阅读仓库并给出计划。
3. 默认交互模式下限定目标文件和验证命令。
4. 修改后运行最小测试，再运行完整测试或构建。
5. 用 git diff --stat 和 git diff 检查范围、敏感文件和依赖变化。
6. 人工 Review 后提交 Git；长任务中断则用 codex resume。

9. Desktop 项目工作流

1. 用 ?O 打开代码目录，或在 Projects 中添加本地项目并指定主文件夹。
2. 新建 Codex 聊天，先让模型只读了解目录、AGENTS.md 和现有测试。
3. 需要多个仓库时，在项目设置中添加次级文件夹；涉及 Git 提交和 worktree 的操作仍以主仓库为准。
4. 通过 /plan 生成计划，通过 /model 和 /reasoning 选择当前任务配置。
5. 需要浏览器、电脑操作或文件预览时，从 Desktop 的工具面板打开对应能力；每次授权前检查目标站点和文件。
6. 修改完成后用 ??G 打开 Review，检查文件清单和差异，再运行内置终端中的测试命令。
7. 长任务可关闭窗口后从项目 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 和测试命令配合，最终以本机帮助和官方文档为准。