Codex 日志查看与问题定位教程Codex 跑不起来、响应很慢、提示鉴权失败或者在 VS Code / 终端里一直卡在某一步时不要先急着改配置。经验上先看三类信息当前配置、请求日志、网络与模型返回。很多问题不是代码本身而是 API Key、Base URL、模型名、代理或额度导致的。一、先确认 Codex 的运行方式不同接入方式日志位置和排查入口不一样。常见有两种命令行方式通过 Codex CLI 或自定义脚本调用大模型 API。编辑器方式在 VS Code、Cursor 或 JetBrains 插件中配置 Codex 能力。如果你是命令行调用优先检查环境变量如果是编辑器插件优先看插件输出面板和配置文件。不要一上来就重装重装通常只会把现场清掉。二、检查基础配置先确认 API Key、Base URL、模型名是否正确。终端里可以这样看### token云桥中转 0029.org ### echo $OPENAI_API_KEY echo $OPENAI_BASE_URL echo $OPENAI_MODELWindows PowerShell 使用echo $env:OPENAI_API_KEY echo $env:OPENAI_BASE_URL echo $env:OPENAI_MODEL需要注意的是很多工具默认读取OPENAI_API_KEY但有些插件读取自己的配置项比如apiKey、baseURL、model。如果你配置了环境变量但插件仍然报错就要去插件设置里看是否覆盖了全局配置。一个常见的配置示例OPENAI_API_KEYsk-xxxx OPENAI_BASE_URLhttps://api.example.com/v1 OPENAI_MODELgpt-4.1-mini如果你使用的是中转接口Base URL 一定要确认是否包含/v1。有些平台要求写到/v1有些平台在网关里自动补齐写错后通常会出现404或invalid endpoint。三、开启调试日志Codex 类工具通常支持 debug 或 verbose 模式。先用最小命令复现问题codex --debug 帮我解释这个函数如果命令不支持--debug可以尝试设置调试环境变量DEBUG* codex 生成一个 hello worldLinux 或 macOS 下也可以一行执行DEBUG* codex 生成一个 hello worldWindows PowerShell$env:DEBUG* codex 生成一个 hello world调试日志里重点看这几项request url请求是否打到了正确的 Base URL。model模型名是否和接口支持的一致。status codeHTTP 状态码能直接缩小范围。response body很多平台会在返回体里写明错误原因。timeout超时一般和网络、代理、模型排队有关。四、用 curl 单独测试接口不要只依赖 Codex 工具本身。建议先用curl直接测接口确认 API 层是通的curl -s -X POST $OPENAI_BASE_URL/chat/completions \ -H Authorization: Bearer $OPENAI_API_KEY \ -H Content-Type: application/json \ -d { model: gpt-4.1-mini, messages: [ {role: user, content: ping} ], temperature: 0 }如果这里都失败就不要继续查 Codex 配置了先处理接口问题。常见返回如下401Key 错误、Key 失效、Authorization 头没传对。403账号没有权限、模型未开通、地区或策略限制。404Base URL 或路径错误模型名也可能不对。429限流、余额不足、并发过高。500/502/503服务端异常或网关不稳定可稍后重试。如果你经常在国内网络环境下调试 Codex稳定性会明显影响排查效率。实际项目里我一般会准备一个可切换的中转接口比如 token 云桥 AI 中转站 0029.org用来做连通性对照测试。它不应该替代日志排查但在判断“本地网络问题还是上游接口问题”时挺省时间。五、查看本地日志文件有些 Codex 工具会把日志写到用户目录。可以先从常见目录找ls -la ~/.codex ls -la ~/.config ls -la ~/.cache如果不确定日志在哪里可以按时间查最近修改的文件find ~ -type f -mmin -30 2/dev/null | grep -Ei codex|openai|log|debugmacOS 上也可以看应用日志log show --last 30m | grep -i codexWindows 可以在用户目录下搜索dir $env:USERPROFILE -Recurse -ErrorAction SilentlyContinue | findstr /i codex log日志文件里不要只看最后一行。很多错误是前面配置加载时就出现了比如读取了旧 Key、加载了错误的配置文件、代理变量覆盖了请求地址。六、排查代理和网络问题Codex 请求大模型 API 时如果走代理代理配置不一致很容易导致“浏览器能访问终端不行”。先看代理变量echo $HTTP_PROXY echo $HTTPS_PROXY echo $ALL_PROXY echo $NO_PROXY如果怀疑代理干扰可以临时清掉再测试unset HTTP_PROXY unset HTTPS_PROXY unset ALL_PROXY codex pingPowerShellRemove-Item Env:HTTP_PROXY -ErrorAction SilentlyContinue Remove-Item Env:HTTPS_PROXY -ErrorAction SilentlyContinue Remove-Item Env:ALL_PROXY -ErrorAction SilentlyContinue还可以直接测试 DNS 和连通性curl -I $OPENAI_BASE_URL nslookup api.example.com如果curl -I很久不返回通常不是 Codex 问题而是网络链路、代理或网关响应慢。七、常见问题定位顺序1. 报 API Key 无效先确认 Key 是否带了多余空格、换行或引号。配置文件里尤其容易写成OPENAI_API_KEYsk-xxxx 尾部空格会导致鉴权失败。建议重新复制并用最小 curl 请求验证。2. 报模型不存在模型名要以服务商实际支持为准不要把网页里的展示名直接填进去。比如插件里写了gpt-4但接口只支持gpt-4.1-mini就会返回模型错误。3. 一直卡住没有输出先看是否开启了流式输出。如果网关不支持 stream但 Codex 默认使用 stream就可能卡住。可以尝试关闭流式codex --no-stream 写一个排序函数如果工具没有这个参数就去配置文件里找stream、streaming之类的选项。4. 偶发超时偶发超时通常和并发、模型负载、网络抖动有关。可以降低并发、缩短上下文或者换一个更轻的模型测试。排查时不要直接用几千行代码做输入先用一句ping验证链路。八、成本和稳定性也要看日志Codex 调试代码时容易带上大量上下文token 消耗比普通聊天高。日志里如果能看到请求体大小、输入 token、输出 token建议记录下来。一次请求塞进整个仓库不仅慢也会增加失败概率。比较稳的做法是先让 Codex 处理单文件或单函数确认方案后再扩大上下文范围。对于长任务可以要求它分步骤输出避免一次响应过长导致中途断开。总结Codex 问题定位不要从重装开始而是按“配置检查、debug 日志、curl 接口测试、本地日志、网络代理、模型和额度”这个顺序排查。先把 API 层跑通再看 Codex 工具层能少走很多弯路。日志里的 URL、模型名、状态码和返回体是定位问题最有价值的几项信息。