直接答案
首次使用不要从大需求开始；选择一个边界清楚的小任务，建立“理解、计划、修改、验证、复核”的闭环。
这篇内容解决什么问题
完成 Codex CLI 第一个可验证的代码任务
选择低风险但真实的任务
理想的首次任务应当只涉及一到两个模块，有明确的完成条件，并且存在可运行的测试、构建或静态检查。修正文案不是验证代理能力的好样本，跨仓库迁移又会引入太多变量。
可以选择补一个缺失边界测试、修复能够稳定复现的错误，或为现有函数增加输入校验。先把目标写成行为变化，而不是指定未经验证的实现。
- 给出复现命令或失败测试。
- 明确允许修改的目录与不能变化的公共接口。
- 指定完成后必须运行的检查。
- 要求列出实际改动和剩余风险。
记录仓库基线
启动 Codex 前先确认当前分支与工作区状态。已有未提交改动不一定要清除，但必须知道哪些变更属于任务开始前，避免后续误判。
测试命令由仓库自身决定。以下示例只负责检查 Git 状态和发现常见项目入口，不假定项目一定使用某个包管理器。
git status --short --branch
git diff --stat
ls
find . -maxdepth 2 -name AGENTS.md -o -name package.json -o -name go.mod -o -name pyproject.toml先理解与计划，再授权修改
第一轮让 Codex 在只读沙箱中定位代码、解释数据流并提出计划。计划应指出具体文件、风险和验证方式；如果它还无法说明失败原因，就不应直接进入修改。
把工作目录通过 -C 明确传入，能减少从错误目录启动导致的上下文偏差。
codex -C /path/to/repo -s read-only "先阅读仓库说明和与登录超时相关的代码。复现现有失败，说明根因，给出精确到文件的修改计划和验证命令。不要修改文件。"用任务契约启动实现
实现提示词应包含问题、范围、约束、验证和停止条件。让 Codex 使用仓库已有模式，并要求遇到需求歧义时先提问。
workspace-write 允许在工作区写入，但系统外路径与受限网络仍由沙箱控制。不要为了省一次审批直接使用无沙箱模式。
codex -C /path/to/repo -s workspace-write -a on-request "修复已确认的登录超时问题。只修改 auth 模块及其测试，保持公共 API 不变；先补回归测试，再实现修复，运行相关测试和格式检查。失败时报告原始错误，不要通过跳过测试或放宽断言绕过。"人类审阅差异，而不是只读总结
模型给出的完成总结不能替代仓库证据。检查实际 diff、未跟踪文件以及是否出现无关格式化；必要时要求 Codex解释每个行为变化。
审阅时重点看边界条件、错误路径、兼容性与秘密泄漏，不要只看测试是否变绿。
git status --short
git diff --check
git diff --stat
git diff运行验证并保留后续上下文
亲自运行仓库权威测试，确认 Codex 展示的结果可以复现。若需要继续同一上下文，使用 resume；若想保留历史同时尝试另一方案，使用 fork。
首次任务完成的标准是行为、测试和差异都符合预期，而不是终端中出现“完成”字样。
# 先运行仓库 AGENTS.md 或 CI 规定的测试命令
git diff --check
codex resume --last
# 或从上一会话创建独立分支上下文
codex fork --last
官方来源与核验范围
本文以公开官方文档为事实依据；命令和配置可能随客户端版本变化，执行前请同时核对对应来源。
查看技术核验方法