本地 Codex 报错 stream disconnected before completion：从 config.toml 到 base_url 的排查与修复记录

1. 本地 Codex 断流报错到底卡在哪一环stream disconnected before completion这个报错字面意思是「流在完成前断开了」但真正让人头疼的是它不告诉你断在哪。你看到的是 Codex 发消息后转了几圈然后甩出一行红字后面跟着一个 URL。这个 URL 才是破案的关键线索。我先把结论摆出来绝大多数本地 Codex 出现这个报错根因不在模型、不在账号、也不在 Codex 本身而在config.toml里残留了一个指向本地端口的model_provider配置块。Codex 老老实实按配置去请求http://127.0.0.1:某端口/v1/responses可那个端口背后根本没有服务在监听请求发出去石沉大海流自然就断了。为什么这个坑这么常见因为很多人之前折腾过本地模型代理、第三方 provider 或者各种「加速」方案在config.toml里写过自定义 provider。后来不用了只把模型名改回官方却忘了删model_provider那一行和对应的[model_providers.xxx]配置块。Codex 的配置优先级里只要model_provider还指向一个存在的 provider 块它就会继续走那条路你改model字段根本没用。这篇文章适合三类人一是刚在本地装好 Codex、第一次遇到断流报错的新手二是之前配过自定义 provider、现在想切回官方登录但一直报错的人三是想搞清楚 Codex 配置加载逻辑、以后能自己排查同类问题的人。我会把排查链路拆成可复制的命令和配置片段从端口检查、环境变量排查、config.toml定位一直到恢复登录和验证请求每一步都给出实际输出长什么样。需要说明的是本文聚焦的是「配置指向了不存在的本地服务」这一类断流。如果你的报错 URL 是https://api.openai.com或https://auth.openai.com开头的那属于网络连通性问题排查思路不同我会在第五节单独讲。先把配置层面的问题理清楚因为这是最高频、也最容易被忽略的一类。整个排查的核心逻辑就一句话顺着报错 URL 里的 host 和 port反查是谁把它写进配置的。URL 指向127.0.0.1那一定是本地某个配置项干的指向公网域名那才轮到网络层。下面按这个思路一步步来。2. 排查前先备好 TaoToken 的接入信息在动手改配置之前有个前置动作值得先做确认你手头有一个稳定可用的 API 接入点。因为不管你最后是切回官方登录还是改用自定义 provider都需要一个明确的base_url和对应的 Key。如果只是把本地代理删掉、又没准备好替代方案Codex 会陷入「没有可用 provider」的状态报错会从断流变成另一种。我自己的做法是准备一个独立的接入配置和 Codex 的官方登录模式分开管理。这样即使本地配置改乱了也能快速切回来验证。TaoToken 的接入信息可以这样拿官网入口是https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content注册后在控制台里能看到 API Key 管理页面。API 的基础地址是https://taotoken.net/api注意这个地址不带任何查询参数配置时直接填这个。具体要准备三样东西我把它整理成一张对照表方便你配置时逐项核对配置项取值来源填写示例注意事项Base URLAPI 地址https://taotoken.net/api不要带末尾斜杠不要加 UTMAPI Key控制台 API Keys 页sk-开头的一串按密钥处理别截图外发Model ID模型列表页按你选的模型填要和 provider 支持的模型名一致拿到这三样之后先别急着往 Codex 里塞。建议先用一个最简单的curl验证这个接入点本身是通的排除掉「Key 无效」「地址写错」这类低级问题再去改 Codex 配置。验证命令在第四节会给。这里要提醒一句config.toml里如果出现experimental_bearer_token sk-xxx这种字段那个 token 就是明文密钥。排查过程中如果要贴配置给别人看务必先把这行删掉或打码。我见过有人把带 token 的配置直接发到群里求助结果 Key 被刷爆。密钥泄露了就去控制台重置别抱侥幸。另外Codex 的配置目录在 Windows 下是C:\Users\你的用户名\.codex\macOS 和 Linux 下是~/.codex/。本文命令以 Windows CMD 为主其他系统把路径换成对应的即可。确认好这个目录后面所有排查都围绕它展开。3. 可复制的 config.toml 配置与端口排查命令这一节是实操核心。我先把「问题配置」和「修复后配置」摆在一起对比你一眼就能看出该删什么、该留什么。先看导致断流的典型问题配置。打开C:\Users\你的用户名\.codex\config.toml如果看到类似下面这样的内容那基本就是它了model_provider CodexPlusPlus model deepseek-v4-flash [model_providers.CodexPlusPlus] name CodexPlusPlus wire_api responses requires_openai_auth true base_url http://127.0.0.1:57321/v1 experimental_bearer_token sk-xxx这段配置的含义是Codex 启动后会走名为CodexPlusPlus的 provider请求地址是http://127.0.0.1:57321/v1并且用的是 Responses APIwire_api responses。问题就出在这个base_url指向了本机 57321 端口而那个端口没有服务。第一步确认端口到底有没有服务在听。在 CMD 里执行netstat -ano | findstr 57321如果输出是空的像这样C:\Users\Lenovonetstat -ano | findstr 57321 C:\Users\Lenovo那就说明 57321 端口没有任何进程在监听Codex 请求它必然失败。如果输出里有LISTENING那说明端口有服务问题可能出在服务不支持/v1/responses这个路径上那是另一回事。第二步排除环境变量干扰。有时候base_url不是写在config.toml里而是通过环境变量注入的。检查一下echo %OPENAI_BASE_URL% echo %OPENAI_API_BASE%如果输出的是变量名本身比如%OPENAI_BASE_URL%说明这个环境变量没设置。如果输出的是一个127.0.0.1开头的地址那就要去系统环境变量里把它删掉。第三步全局搜索配置目录里还有没有残留。这条命令很实用能一次性把可疑字段都揪出来findstr /S /I /N 57321 CodexPlusPlus model_provider base_url %USERPROFILE%\.codex\*它会递归搜索.codex目录下所有文件把包含这些关键词的行连行号一起列出来。重点看config.toml但也要留意有没有别的配置文件在偷偷覆盖。确认问题后修复方案有两种。方案一是你确实想继续用本地代理那就去把那个服务重新启动起来启动后再用netstat确认端口在听并且确认它支持/v1/responses路径——很多本地代理只支持/v1/chat/completions路径对不上照样报错。方案二是切回官方登录模式把自定义 provider 整块删掉。我采用的是方案二修复后的最小可用配置长这样model gpt-5.5 forced_login_method chatgpt disable_response_storage true关键点必须删掉model_provider CodexPlusPlus这一行以及整个[model_providers.CodexPlusPlus]配置块。只改model字段是没用的只要model_provider还在Codex 就继续走自定义 provider。这一点我踩过坑改了半天模型名报错纹丝不动最后才发现是 provider 没删干净。如果你选择用 TaoToken 作为自定义 provider配置片段可以这样写把 Base URL、Key、Model ID 三件套填全model_provider taotoken model 你的模型ID [model_providers.taotoken] name taotoken wire_api chat base_url https://taotoken.net/api experimental_bearer_token 你的API Key注意wire_api这里填chat还是responses要看你选的模型和接入点支持哪种协议。填错了会报路径 404 或协议不匹配。改完配置保存下一步就是重新登录和验证。4. 重新登录并验证请求是否恢复配置改完之后Codex 不会自动生效需要重新走一遍登录流程让它重新读取配置并建立会话。这一步在 CMD 里依次执行codex logout codex logincodex logout会清掉本地缓存的登录态codex login会拉起浏览器授权。如果浏览器打不开或者卡住可以用设备码登录codex login --device-auth它会给你一个码让你在另一个能上网的设备上打开指定页面输入。登录完成后用这条命令确认状态codex login status正常输出应该是Logged in using ChatGPT看到这行说明 Codex 已经切回 ChatGPT 账号登录模式不再走那个不存在的本地端口了。这时候再启动codex如果一切正常你会看到类似这样的启动界面╭───────────────────────────────────────╮ │ _ OpenAI Codex (v0.142.0) │ │ │ │ model: gpt-5.5 /model to change │ │ directory: ~ │ ╰───────────────────────────────────────╯到这一步断流问题基本就解决了。但我想强调一个验证习惯别只看启动界面要实际发一条消息测一下。启动成功不代表请求链路通有些配置问题要等到真正调用模型时才暴露。发一条简单消息比如「你好回复一个字」看它能不能正常流式返回。如果你用的是自定义 provider比如上面那段 TaoToken 配置在改 Codex 之前建议先用curl单独验证接入点本身是通的把 Codex 配置问题和接入点问题分开排查curl -I https://taotoken.net/api这条命令看的是接入点能不能连通返回200或401都说明网络层是通的401只是没带 Key。如果要验证 Key 和模型是否可用用带鉴权的请求curl https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer 你的API Key \ -H Content-Type: application/json \ -d {model:你的模型ID,messages:[{role:user,content:hi}]}返回里有正常的choices字段就说明 Base URL、Key、Model ID 三件套都对。这时候再回到 Codex 里测如果 Codex 还报错那问题一定在 Codex 的配置加载上而不是接入点。验证通过后建议把当前可用的config.toml备份一份命名成config.toml.bak。下次再改配置改乱了直接覆盖回来能省很多排查时间。这个习惯我坚持了很久救过我好几次。5. 同类报错对照排查401、OAuth 与路径不匹配断流报错不止一种面孔同一个stream disconnected before completion背后可能是完全不同的原因。这一节我把几种高频变体列出来对照着排查能少走很多弯路。变体一URL 指向127.0.0.1但端口有服务仍报断流。这种情况多半是本地代理不支持/v1/responses路径。Codex 的wire_api responses会请求/v1/responses而很多本地模型代理只实现了/v1/chat/completions。你可以在浏览器或curl里直接访问那个路径验证curl -I http://127.0.0.1:57321/v1/responses如果返回404说明路径不存在要么换支持 Responses API 的代理要么把wire_api改成chat并确认代理支持 chat 协议。变体二报错变成token exchange failedURL 是https://auth.openai.com/oauth/token。这个和本地端口无关是登录最后一步访问授权接口失败。常见原因是网络环境访问不了该域名。先用curl测连通性curl -I https://auth.openai.com/oauth/token curl -I https://api.openai.com curl -I https://chatgpt.com如果这几条都超时或连不上那就是网络层问题需要换一个能正常访问这些域名的网络环境。注意这里说的是网络连通性不是让你去搞什么特殊工具就是确认当前网络能不能到达这些地址。变体三报错里出现401 Unauthorized或invalid api key。这是鉴权失败和断流是两码事。检查config.toml里的experimental_bearer_token是否填对、有没有多余空格、Key 是否已过期或被重置。如果你用的是自定义 provider确认base_url和 Key 是配套的——拿 A 家的 Key 去请求 B 家的地址必然 401。变体四报错里出现local proxy failed或connection refused。这是典型的「配置指向本地但服务没起」。回到第三节的netstat命令确认端口状态。connection refused比断流更直接它明确告诉你目标端口拒绝连接。变体五启动时出现Skipped loading 1 skill(s) due to invalid SKILL.md files。这个黄色警告和断流无关是本地 skill 文件格式问题。报错会指出具体文件路径比如C:\Users\Lenovo\.agents\skills\roadshow\SKILL.md: missing YAML frontmatter。解决方式是在该文件顶部补上 YAML frontmatter--- name: roadshow description: 用于生成、优化和审查路演脚本、路演方案、演示材料和客户沟通内容。 --- # 路演材料 Skill 这里保留原来的 skill 内容。保存后重启 Codex警告就消失了。这个不影响模型调用但看着烦顺手修掉。排查这类问题的通用心法是先看报错 URL 的 host。127.0.0.1或localhost开头去查配置和本地端口公网域名开头去查网络连通性和鉴权。把这两类分开排查效率会高很多。我见过有人一遇到断流就去换网络结果折腾半天发现是配置里残留了一个本地端口方向错了白费劲。6. 稳定调用与后续配置管理建议问题解决之后更重要的是别再掉进同一个坑。我把自己踩过的坑和总结的习惯整理成几条你可以直接拿去用。第一条改配置前先备份。config.toml改之前复制一份成config.toml.bak放在同目录。改坏了直接覆盖回来比对着报错一行行找快得多。这个动作花不了十秒但能省半小时。第二条切换 provider 时删干净再新增。不要在一个配置里同时留着多个model_provider指向和多个[model_providers.xxx]块。Codex 只会用model_provider指定的那一个其余的留着只会干扰排查。切回官方登录时model_provider这一行和对应的 provider 块一起删。第三条密钥永远按密钥对待。config.toml里的experimental_bearer_token、环境变量里的OPENAI_API_KEY都不要出现在截图、聊天记录、公开仓库里。如果怀疑泄露第一时间去对应平台重置。我习惯把配置里的 token 用占位符sk-xxx代替后再分享真要贴给别人看先替换掉。第四条验证链路要分层。接入点通不通用curl测Codex 配置对不对用codex login status看模型能不能调发一条真实消息测。三层分开验证哪层出问题一目了然不会眉毛胡子一把抓。第五条保留一份最小可用配置。我常备一份只有三行的config.tomlmodel gpt-5.5 forced_login_method chatgpt disable_response_storage true遇到任何配置相关的诡异报错先用这份最小配置跑通确认基础链路没问题再往上加自定义 provider。这样能快速判断问题出在基础层还是扩展层。如果你需要长期做编码类任务、跑 Agent 工作流可以考虑用 Coding Plan 这类方案来管理调用配额和模型选择入口在https://taotoken.net/api对应的控制台里能找到。模型对话验证可以去模型对话页面直接测接入文档在文档页有完整说明。API Key 的创建和管理在控制台的 API Keys 页面。最后说一个我自己的经验Codex 的配置问题九成以上都能用「看报错 URL 的 host 查config.tomlnetstat查端口」这三步定位。真正需要动网络层的情况反而少。所以下次再遇到stream disconnected before completion先别急着换网络打开config.toml看一眼有没有残留的model_provider和base_url大概率问题就在那儿。