1. 401 不是模型问题，先看鉴权头

如果你同时跑过 ChatGPT API、OpenAI SDK 和 Codex CLI，切到兼容端点后最常见的报错不是“模型不存在”，而是 401。多数情况不是服务挂了，而是 Authorization 头没带对、base_url 配错，或者环境变量串了：CLI 读到旧的 OPENAI_API_KEY，但 OPENAI_BASE_URL 指向了新地址，结果请求落到错误网关。很多兼容端点仍按 OpenAI 习惯收 Bearer sk-...，所以不要手动去掉 Bearer，也不要把 key 写进 URL。

export OPENAI_API_KEY="sk-xxxx"
export OPENAI_BASE_URL="https://59api.com/v1" # 本地调试时我用过 兼容端点，可替换
export OPENAI_MODEL="gpt-4.1-mini"

# 先看 CLI 实际读到什么
env | grep -E 'OPENAI|CODEX'

# 直接验证鉴权和路由
curl -N https://example.com/v1/chat/completions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"gpt-4.1-mini","messages":[{"role":"user","content":"ping"}],"stream":true}'

2. 流式 SSE 和超时，别把 401 误判成网络抖动

Codex CLI 开流式输出时走的是 SSE，兼容端点如果代理层不支持 text/event-stream，会出现“卡住几秒后退出”，表面像超时，日志里却可能先有 401 或 403。建议先关掉重试，单次请求验证：如果非流式正常、流式失败，问题通常在网关的 chunk 转发、gzip 或超时配置。另一个常见坑是模型路由：你传了 gpt-4.1，但服务端只映射到 gpt-4.1-mini，会返回鉴权成功但业务失败，所以要确认后端支持的模型名和你 CLI 里填写的一致。

3. 迁移检查清单

1. 只保留一套环境变量，清掉旧的 OPENAI_API_BASE / OPENAI_BASE_URL 冲突项。

2. 确认 Authorization: Bearer 没被壳脚本二次包装。

3. 先用 curl 验证再跑 Codex CLI，分离“接口问题”和“工具问题”。

4. 测试流式与非流式两种模式，排查 SSE。

5. 检查模型路由、超时、重试和代理层日志。

如果你是从官方 OpenAI 切到兼容端点，这套排查顺序基本能把 401、超时和流式断连一次定位出来。