Codex 命令行总读到旧 API 地址怎么办？
Codex 命令行明明改了 API 地址却仍走旧接口时，先按系统环境变量、项目配置、终端缓存和固定测试请求确认真实生效来源。
适用场景：改了地址但请求还在走旧线路
这个问题常出现在新手把 AI API 接入地址从测试环境改到正式环境，或者把 Codex 接入从直连改为 CCSwitch 配置之后。网页后台显示已经保存，配置文件也看起来正确，但命令行里的请求仍然打到旧 base_url，表现为 401、404、模型不存在、余额不对或日志里出现旧域名。永沃云枢在 https://ai.jn83.com 做日常排查时，会先确认真实生效来源，而不是只相信界面上最后一次点击。
还要注意一个搜索词误区：很多人会把这类问题叫做“GPT 中转不生效”，更准确的说法是 AI 模型接口接入与调用管理里的配置优先级冲突。Codex 命令行可能读取系统环境变量、用户目录配置、项目本地配置、当前终端临时变量、代理工具 profile 或启动脚本里的覆盖值。只改其中一个位置，未必能改变最终请求。
操作步骤：从当前终端开始查，不从记忆里猜
第一步，打开真正运行 Codex 的同一个终端，查看当前环境变量。Windows 可用 `Get-ChildItem Env:` 搜索 API、BASE、PROXY、MODEL 等关键字段；macOS 或 Linux 可用 `env | grep -Ei 'api|base|proxy|model'`。如果这里出现旧地址，先记录变量名、来源和作用域，再决定是临时清除还是永久修改。
第二步，检查项目目录和用户目录里的配置文件。很多 CLI 工具会按当前目录、用户目录、全局配置的顺序读取。不要只看仓库根目录，也要看启动脚本、`.env`、PowerShell profile、npm script、批处理文件和服务管理配置。每找到一个候选值，都写下路径和读取顺序。
第三步，用固定测试请求验证。不要一上来跑完整任务，先用一个最小模型列表或短问答请求，记录 base_url、模型名、状态码、request_id 和响应头。若 CCSwitch 配置参与路由，还要在 CCSwitch 界面确认当前 profile、Key 尾号和模型别名是否与命令行一致。
第四步，重启终端而不是只重启 Codex。很多环境变量在终端会话启动时已经固定，修改系统变量后旧窗口不会自动刷新。重启后再运行同一条测试命令，对比日志是否进入新地址。必要时把旧变量改名暂存，而不是直接删除，方便回滚。
排错路径：按优先级缩小配置冲突
如果日志里仍出现旧地址，先排查启动脚本是否覆盖。比如快捷方式、计划任务、CI 配置、IDE 终端和本机 PowerShell profile 都可能预先写入变量。其次排查代理工具，尤其是 CCSwitch 多 profile 时，界面选中的 profile 和 Codex 实际读取的 profile 可能不是同一个。
如果地址已正确但仍失败，再看 Key 权限、模型名和证书。地址冲突修好后暴露 401 或 404 是正常现象，说明请求至少到了新服务。此时不要回退配置，而是按 AI API 接入的错误字段继续排查。涉及团队共用时，应把变更写入配置变更记录，说明谁改了哪个变量、何时生效、如何验证。
常见问题/避坑：别把旧窗口当成新配置
最常见的坑是修改了系统环境变量，却继续在旧终端里测试。第二个坑是只改 base_url，没有同步模型名，导致新接口收到旧模型别名。第三个坑是把 Key 明文贴进排查记录，建议只保留尾号和权限范围。第四个坑是同时修改 Codex、CCSwitch 和项目脚本，最后无法判断哪个动作真正生效。
还有一种情况是线上服务、静态文章和首页说明已经写新地址，但本机开发环境仍保留旧地址。此时要分别标注“文档展示值”“本机运行值”“代理转发值”和“服务端日志值”，不要把不同层级混在一起比较。
检查清单：确认真实生效再交付
当前终端环境变量已截图或导出；项目配置、用户配置和启动脚本已列路径；最小请求能打到新 base_url；CCSwitch profile、模型名和 Key 尾号一致；旧变量已清理或标注为停用；验收记录能说明已提交的是配置变更，不承诺搜索引擎已收录任何页面。
FAQ：可以完全交给 Codex 或模型自动处理吗？
可以让 Codex 帮你收集文件、执行低风险检查、整理日志和生成初稿，但涉及生产配置、用户数据、金额、权限、正式发布和搜索提交时，仍要保留人工确认点。自动化的目标是减少重复操作，不是绕过验收。