1. Linux 服务器上 codex 登录卡住到底卡在哪一步如果你在 Linux 服务器上跑 codex登录时看到Token exchange failed或者operation timeout大概率不是你的账号有问题而是认证链路里某个环节没走通。codex 的登录流程本质上是本地发起认证请求 → 浏览器完成授权 → 回调把授权码换回 token → token 写入本地配置。服务器端没有图形界面浏览器这一步往往要靠端口转发或者手动粘贴回调地址任何一个环节断了都会表现为Token exchange failed或超时。我试过在一台只有 SSH 的 Ubuntu 机器上装 codex第一次登录就卡在Token exchange failed重试几次变成operation timeout。后来发现是两个问题叠加一是本地~/.codex目录下没有正确的配置文件二是服务器出站请求没有走通。这篇文章就把这套排查过程拆开给你一份可以直接复制的config.toml骨架以及用 curl 逐步定位超时环节的方法。适合谁看需要在无图形界面的 Linux 服务器上完成 codex 认证、并且希望把请求统一走一个稳定 API 通道的开发者。下面所有命令和配置都可以直接跟做遇到报错对照第 5 节的排查清单。2. 前置准备TaoToken 统一 Key 与 API 通道在服务器上折腾 codex最烦的是认证和网络两件事混在一起。我的做法是把模型请求统一走 TaoToken 的 API 通道这样 Key 管理、额度、模型切换都在一个地方codex 这边只需要填一个 base_url 和一个 Key。TaoToken 是一个大模型 API 聚合平台兼容 OpenAI 风格的接口你可以用同一个 Key 调用不同模型。对服务器端 codex 来说好处是不用在每台机器上分别配置各家厂商的 Key出站地址固定排查超时的时候变量更少。你需要先拿到一个 API Key。登录官网后进入控制台在 API Keys 页面创建一个新 Key复制保存。注意 Key 只在创建时完整显示一次丢了就重新建一个。官网入口https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content控制台创建 Keyhttps://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewriteAPI Keys 管理页https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewriteAPI 的基础地址是https://taotoken.net/api注意这个地址后面不加 UTM 参数直接作为 base_url 使用。拿到 Key 之后先别急着配 codex用 curl 验证一下通道是否通这一步能帮你把「网络问题」和「codex 配置问题」分开。curl -sS https://taotoken.net/api/v1/models \ -H Authorization: Bearer sk-你的Key \ -o /tmp/models.json -w http_code%{http_code} time_total%{time_total}\n如果返回http_code200说明 Key 和出站通道都没问题可以进入下一步。如果卡住或者返回 401/403先解决 Key 和网络再动 codex 配置。3. 可复制的 config.toml 骨架与 .env 配置codex 在服务器端的配置目录默认是~/.codex。先确认目录存在不存在就手动建mkdir -p ~/.codex ls -la ~/.codex3.1 config.toml 骨架下面这份config.toml是我在服务器上实测能用的骨架把模型请求指向 TaoToken 的 API 通道。你可以直接复制替换model为你实际要用的模型名。# ~/.codex/config.toml model gpt-4o-mini model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api/v1 env_key TAOTOKEN_API_KEY wire_api chat [history] persistence save-all [tools] web_search false几个关键点说明base_url必须带/v1因为 codex 走的是 OpenAI 兼容的 chat completions 接口。env_key指定从哪个环境变量读取 Key这里用TAOTOKEN_API_KEY和后面的.env对应。wire_api chat表示用 chat 接口而不是 responses 接口兼容性更好。3.2 .env 文件在~/.codex下创建.env写入 Keycat ~/.codex/.env EOF TAOTOKEN_API_KEYsk-你的Key EOF chmod 600 ~/.codex/.envchmod 600是必须的避免 Key 被其他用户读到。codex 启动时会自动加载这个文件里的环境变量。注意如果你之前按网上教程配过HTTPS_PROXY之类的变量先确认那个地址在服务器上真的可达。很多operation timeout就是因为代理地址在服务器上根本连不通反而把正常请求也带偏了。3.3 关于登录缓存excerpt 里提到清auth.openai.com的 localStorage 缓存那是浏览器端的操作。在纯服务器环境下对应的做法是清理~/.codex下的认证缓存文件ls -la ~/.codex/ # 如果有 auth.json / credentials.json 之类的缓存先备份再删 mv ~/.codex/auth.json ~/.codex/auth.json.bak 2/dev/null || true清掉旧缓存再重新登录能避免用过期 token 去换新 token 导致的Token exchange failed。4. 验证请求用 curl 和 codex 复现成功结果配置写完之后分两步验证。先验证 API 通道再验证 codex 本身。4.1 验证 chat 接口source ~/.codex/.env curl -sS https://taotoken.net/api/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: gpt-4o-mini, messages: [{role: user, content: ping}], max_tokens: 16 } -w \nhttp_code%{http_code} time_total%{time_total}\n返回里有choices字段且http_code200说明通道完全通。如果这里就超时问题在服务器出站网络不在 codex。4.2 验证 codex 登录codex --version codex login如果登录流程需要浏览器回调服务器端通常会给一个 URL你在本地浏览器打开完成授权再把回调地址粘回终端。这一步如果报Token exchange failed重点看终端输出的完整错误通常会带 HTTP 状态码。登录成功后跑一个最小请求确认端到端可用codex exec print hello能正常返回内容说明从登录到模型调用整条链路都通了。实测下来只要第 4.1 步的 curl 是 200codex 这边基本不会再出operation timeout。5. 本篇常见错排查清单把我在服务器上踩过的坑按现象列出来对照排查。5.1 Token exchange failed这个报错发生在「拿到授权码、去换 token」这一步。常见原因有三个一是~/.codex下的旧缓存 token 过期换的时候被拒二是系统时间不对服务器时间偏差超过几分钟会导致签名校验失败三是回调地址和实际请求地址不一致。排查顺序先date看时间再清缓存重登最后检查回调地址。date timedatectl status 2/dev/null | head -5时间不对就同步sudo timedatectl set-ntp true5.2 operation timeout超时基本是网络层的问题。先用第 4.1 步的 curl 测通道如果 curl 也超时按下面顺序查# 1. DNS 解析 getent hosts taotoken.net # 2. TCP 连通性 curl -sS -o /dev/null -w connect%{time_connect} total%{time_total}\n \ https://taotoken.net/api/v1/models \ -H Authorization: Bearer $TAOTOKEN_API_KEY # 3. 看是否有代理变量干扰 env | grep -i proxy如果env | grep -i proxy输出了你之前配的代理地址而那个地址在服务器上不可达就会导致所有请求都超时。临时清掉再测unset HTTPS_PROXY HTTP_PROXY ALL_PROXY5.3 配置不生效codex 读的是~/.codex/config.toml如果你在项目目录下也放了 config注意优先级。确认实际加载的配置codex config get model 2/dev/null || cat ~/.codex/config.toml另外.env文件的权限如果是 644某些版本会拒绝加载统一改成 600。5.4 模型名不对model字段填了 TaoToken 不支持的模型名会返回 404 或 model not found。先用第 4.1 步的/v1/models接口列出可用模型再填进 config.toml。现象最可能原因快速验证Token exchange failed缓存过期 / 时间偏差date 清缓存重登operation timeout出站网络 / 代理变量curl 测通道 env grep proxy401 / 403Key 错误或未加载source ~/.codex/.env后重测model not found模型名不支持调/v1/models核对6. 后续怎么用按场景选对入口服务器端 codex 跑通之后日常使用会分几种情况入口不一样别都堆到一个页面上。如果你只是想在服务器上快速验证某个模型能不能用、对比一下输出直接用模型对话页面最省事不用改任何本地配置https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite如果你是要长期在服务器上跑编码任务、接 Agent 工作流建议用 Coding Plan额度和调用方式更适合持续性的编码场景https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite如果排查过程中发现是 Key 或接入参数的问题回到 API Keys 页面重新生成再对照接入文档核对 base_url 和 header 格式https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 和 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite最后留一个我自己的习惯每次改完config.toml先跑一遍第 4.1 步的 curl再跑codex exec print hello。这两步都过再去干正事能省掉大量「以为是 codex 的锅、其实是网络」的排查时间。