Codex CLI 调试指南
Verbose 模式 · 日志级别 · Dry-run 预演 · 常见失败模式排查
codex --version 确认。
1. 为什么需要调试 Codex?
Codex CLI 是 AI 代理——它接收任务、规划步骤、调用工具(写文件/执行命令)、等待反馈。当它"卡住"或行为不符合预期时,原因可能来自多个层次:
| 层次 | 表现 | 调试方向 |
|---|---|---|
| 网络层 | 无任何输出,长时间等待 | --verbose 检查连接 |
| 认证层 | 401 / 403 错误 | 检查 API Key 与环境变量 |
| 模型层 | 回答质量差、幻觉频繁 | 日志看 prompt,调整 AGENTS.md |
| 工具调用层 | 写错文件、命令失败 | dry-run 预演,缩小任务范围 |
| 速率限制层 | 429 Too Many Requests | 日志确认,切换模型或降频 |
掌握几个调试工具,大多数问题 5 分钟内可定位。
2. --verbose 标志:最快的调试开关
--verbose(简写 -v)是最常用的调试手段,在交互模式和非交互模式下都有效。
交互模式
# 以详细模式启动交互会话
$ codex --verbose
# 简写
$ codex -v
非交互模式 (exec)
$ codex exec --verbose "给 auth.py 补充单元测试"
# 同时指定模型
$ codex exec -v --model o4-mini "优化这个 SQL 查询"
--verbose 输出哪些内容?
- HTTP 请求:发往 OpenAI API 的每一次请求(URL、状态码、耗时)
- Token 用量:每轮对话的 prompt tokens / completion tokens
- 工具调用:Codex 调用哪个工具(write_file、run_command 等)及参数
- Sandbox 事件:沙箱中命令的执行结果和退出码
- 错误详情:完整的错误堆栈(普通模式只显示简要信息)
codex -v 2>&1 | tee codex-debug.log
3. CODEX_LOG_LEVEL:精细控制日志
环境变量 CODEX_LOG_LEVEL 提供比 --verbose 更细粒度的控制。
| 级别 | 输出内容 | 适用场景 |
|---|---|---|
error | 仅错误(默认) | 日常使用 |
warn | 警告 + 错误 | 留意潜在问题 |
info | 基本运行信息 | 了解执行流程 |
debug | API 请求/响应、工具调用完整参数 | 深度排错 |
trace | 所有内部事件(非常详细) | 开发 / Bug 报告 |
# 当次会话临时生效
$ CODEX_LOG_LEVEL=debug codex
# 持久写入 shell 配置
$ echo 'export CODEX_LOG_LEVEL=info' >> ~/.zshrc
# 非交互模式也有效
$ CODEX_LOG_LEVEL=debug codex exec "生成 API 文档" 2> debug.log
debug 级别的典型输出样例
[debug] POST https://api.openai.com/v1/chat/completions 200 (1243ms)
[debug] usage: { prompt_tokens: 3842, completion_tokens: 156, total_tokens: 3998 }
[debug] tool_call: write_file { path: "src/auth.test.ts", content: "..." }
[debug] sandbox: run_command "npm test" exit=0
debug/trace 级别会在日志中输出 prompt 内容(截断),其中可能包含代码文件内容。避免在公共日志平台存储这些日志。
4. --dry-run:执行前预演
--dry-run 让 Codex 规划完整的执行步骤,但不实际修改任何文件或执行任何命令。非常适合在高风险操作前验证 Codex 的理解。
# 查看 Codex 会如何重构,不实际修改
$ codex exec --dry-run "将 user_controller.py 中所有同步函数改成 async"
# 危险操作前必须预演
$ codex exec --dry-run "删除 src/ 下所有 .bak 文件"
# 配合 verbose 获取更多细节
$ codex exec --dry-run --verbose "重构数据库连接池"
dry-run 输出示例
📋 Planned actions (DRY RUN — nothing will be executed):
Step 1: Read user_controller.py
Step 2: Identify synchronous function definitions (found 7)
Step 3: Rewrite functions with async/await patterns
Step 4: Update import: add 'asyncio'
Step 5: Write modified file → user_controller.py
Files that WOULD be modified: [user_controller.py]
Commands that WOULD run: none
Total estimated tokens: ~4200
何时用 dry-run?
- 任务涉及删除文件或大范围修改时
- 在 CI/CD 流水线中,先 dry-run 验证 Codex 理解任务再真正执行
- 给新团队成员演示 Codex 会做什么
- 调试 prompt 写法:比较不同 prompt 的 planned actions
5. 读懂日志输出
开启 verbose 后,日志量可能很大。以下是关键字段的解读:
HTTP 状态码
| 状态码 | 含义 | 处理方案 |
|---|---|---|
200 | 正常 | — |
401 | API Key 无效或未配置 | 检查 OPENAI_API_KEY,或 codex login |
403 | 权限不足 / 地区限制 | 确认账号类型,检查代理出口 |
429 | 速率限制(Rate Limit) | 等待 60s,或切换到使用率低的模型 |
500/503 | OpenAI 服务端错误 | 查看 status.openai.com,稍后重试 |
ECONNREFUSED | 连接被拒绝 | 代理未运行或端口错误 |
ETIMEDOUT | 连接超时 | 代理延迟过高或 DNS 污染 |
Token 用量解读
[debug] usage: {
prompt_tokens: 12453, ← 发送给模型的 token(含上下文)
completion_tokens: 892, ← 模型生成的 token
total_tokens: 13345 ← 本轮总消耗
}
prompt_tokens 超过 15,000 时需要考虑:
- 用
.codexignore排除不必要的文件 - 优化
AGENTS.md,减少冗余说明 - 将大任务拆分为多个小任务
工具调用日志
[debug] tool_call: read_file { path: "src/api/users.ts" }
[debug] tool_call: write_file {
path: "src/api/users.ts",
content: "import { ... }" ← 截断显示
}
[debug] tool_call: run_command { command: "npx tsc --noEmit" }
[debug] sandbox: exit=2, stderr: "error TS2345: ..."
6. 五种常见失败模式
模式 1:Codex 启动后无任何输出
codex,光标一直闪烁,什么都不显示,也不报错。
排查步骤:
# 步骤 1:开启 verbose,看有没有网络请求
$ codex --verbose
# 步骤 2:测试代理是否工作
$ curl -v https://api.openai.com/v1/models \
-H "Authorization: Bearer $OPENAI_API_KEY"
# 步骤 3:确认代理变量已设置
$ env | grep -i proxy
常见原因:未设置 HTTPS_PROXY;代理进程没有运行;socks5 代理(Codex 不支持,需转 http)。
模式 2:回答质量差、任务理解偏差
排查步骤:
# 步骤 1:用 dry-run 验证 Codex 的执行计划
$ codex exec --dry-run "[你的任务]"
# 步骤 2:查看 debug 日志中的 prompt 内容
$ CODEX_LOG_LEVEL=debug codex exec "[任务]" 2> prompt-debug.log
# 步骤 3:添加 AGENTS.md 明确约束
$ codex /init # 生成 AGENTS.md 草稿
解决方案:在 prompt 中明确指定文件路径;完善 AGENTS.md 中的项目结构说明;将模糊的大任务拆成具体的小步骤。
模式 3:429 速率限制频繁触发
[error] 429 Too Many Requests,任务中断。
# 查看哪个模型在触发 429
$ CODEX_LOG_LEVEL=info codex exec "..." 2>&1 | grep -i "429\|model\|rate"
# 切换到使用率低的模型
$ codex exec --model gpt-4.1-mini "..."
# config.toml 设置默认模型
# model = "gpt-4.1-mini"
解决方案:等待 60 秒后重试;切换模型(o4-mini → gpt-4.1-mini);升级 API 配额等级;将批量任务分散到多个时间段。
模式 4:沙箱命令失败
# 在 verbose 日志中查看沙箱命令输出
$ codex --verbose
# 查找类似:[debug] sandbox: exit=1, stderr: "..."
# 在 AGENTS.md 中指定测试命令,让 Codex 能自我验证
# ## 测试
# - 始终运行 `npm test` 验证修改
# - TypeScript: `npx tsc --noEmit` 检查类型
解决方案:在 AGENTS.md 明确指定项目的编译/测试命令;Codex 在沙箱中执行失败后会尝试自动修复,确保审批模式允许(auto-edit 或 full-auto)。
模式 5:认证失效 / 会话中断
# 检查两种认证方式是否冲突
$ env | grep OPENAI_API_KEY # 有输出说明用 API Key
$ cat ~/.codex/auth.json 2>/dev/null # 有内容说明用 OAuth
# 冲突时清除 OAuth,只用 API Key
$ rm ~/.codex/auth.json
$ export OPENAI_API_KEY="sk-..."
# 或只用 OAuth,不设 API Key
$ unset OPENAI_API_KEY
$ codex login
7. 调试检查清单
遇到问题时,按顺序逐项确认:
8. 常见问题
如何开启 Codex CLI 的详细日志?
两种方式:① 运行时加 --verbose(codex --verbose);② 设置环境变量 CODEX_LOG_LEVEL=debug。前者只影响当次会话,后者持久生效。
Codex dry-run 是什么?
codex exec --dry-run '任务' 会让 Codex 规划执行步骤但不实际写文件或运行命令,可用于验证 Codex 的理解是否正确,再决定是否真正执行。
Codex 卡住没有输出怎么办?
先用 --verbose 排查:若无网络日志说明连接失败;若有 API 日志但无结果说明模型端问题。常见原因:代理未设置、API Key 无效、速率限制(429)。
如何查看 Codex 的 API 请求内容?
设置 CODEX_LOG_LEVEL=debug 后日志会输出发送到 API 的完整 prompt(截断版本),以及返回的 token 用量,帮助你优化 context 写法。
能把调试日志保存到文件吗?
可以:codex -v 2>&1 | tee codex-debug.log(交互模式),或 CODEX_LOG_LEVEL=debug codex exec "..." 2> debug.log(非交互模式)。日志默认输出到 stderr,2> 重定向 stderr 即可。