表面现象为什么这么像“已经成功了”#

这个问题最容易误导人的地方，就是前半段流程太正常了。

我当时看到的是：

• OpenCode 能正常拉起浏览器授权页
• 浏览器里 OpenAI 登录和授权都能完成
• 回到终端后，也能看到本地回调已经发生

如果只看这几步，几乎很难不相信“登录已经结束了”。

但后来我才意识到：浏览器授权成功，不等于整个 CLI 登录流程已经完整成功。

原因是 OAuth 这类流程通常不只是一句“浏览器点完确认就结束”。浏览器完成授权之后，CLI 往往还要继续做一件关键的事：

• 拿着回调带回来的信息
• 再向服务端发起一次 token exchange
• 把最终拿到的令牌写回本地状态文件

如果这一步失败，前面再顺也没用。

真正的线索，不在页面，而在本地状态和错误信息#

后来继续排查时，两个现象开始把问题指向同一个地方。

第一，OpenCode 里 provider 没有出现。

第二，本地认证状态文件里也没有 OpenAI 条目。

我当时检查到的情况是，~/.local/share/opencode/auth.json 里只有 GitHub Copilot 的记录，没有 OpenAI。这个现象很关键，因为它基本说明：

• 不是单纯 UI 没刷新
• 而是 OpenCode 根本没有把 OpenAI 这次登录结果成功落盘

继续往下看日志后，真正的报错也出来了：

1
Token exchange failed: 403

到这里，问题的性质就变了。

它已经不是“OpenCode 有没有识别到 provider”的问题，而是OpenCode 在授权回调之后，继续向 OpenAI 服务端换取 token 的那一步失败了。

根因不是账号没登上，而是代理环境变量没配完整#

最后把整个链路串起来之后，根因其实非常具体：

我当时的终端环境里，只设置了 ALL_PROXY，但没有单独设置 HTTP_PROXY 和 HTTPS_PROXY。

这件事之所以坑，是因为它会制造一种很强的错觉：

• 浏览器本身能打开授权页
• 某些请求看起来也能走代理
• 但 CLI 进程里真正负责后续联网的那部分请求，不一定会按你想象的方式使用 ALL_PROXY

也就是说，前半段浏览器授权能成功，并不能证明 OpenCode 后续那次 token exchange 也一定成功。

对很多命令行工具来说，尤其是 OAuth 这种“浏览器授权 + 本地回调 + 服务端换 token”的流程，HTTP_PROXY 和 HTTPS_PROXY 往往才是更关键、更稳定的代理入口。

我这里最终就是卡在这一步：

• 浏览器能打开
• 回调能回来
• 但 token exchange 没有正确走代理
• 最终返回 403
• 所以本地没有写入 OpenAI 认证状态
• provider 列表里自然也不会出现 OpenAI

这个问题为什么容易被误判成 UI 刷新问题#

回头看，这类问题真的很容易被误判成“界面没更新”。

因为从用户视角看，最直观的现象只有一个：

我明明都登录成功了，为什么界面里还是没有。

但这里面有一个很重要的排障思路：

我最后是怎么修好的#

修复方式其实不复杂，关键是把代理变量补完整。

除了已有的 ALL_PROXY，还需要把 HTTP_PROXY 和 HTTPS_PROXY 一并设置好，让 OpenCode 在后续联网时明确走代理。

例如：

1
export ALL_PROXY=http://127.0.0.1:7890
2
export HTTP_PROXY=http://127.0.0.1:7890
3
export HTTPS_PROXY=http://127.0.0.1:7890

如果你用的是 socks 代理，就按你实际代理类型替换，但核心思路不变：

• 不要只配 ALL_PROXY
• 把 HTTP_PROXY 和 HTTPS_PROXY 也补齐

补完之后，再重新走一次 OpenCode 的登录流程，问题就能闭环了。

如果你也遇到同样现象，我建议按这个顺序查#

如果你现在遇到的是：

• 浏览器授权成功
• 终端回调成功
• 但 provider 还是不出现

我会建议优先按下面这个顺序排查：

1
Token exchange failed: 403

这次排查给我的一个提醒#

这次问题最后其实不是 OpenAI 登录失败，也不是 OpenCode 单纯没刷新，而是一个很典型的 CLI 网络环境问题。

如果要把这次经验总结成一句话，我会写成：

网页登录成功 + 本地回调成功，并不代表命令行工具后续的 token exchange 也一定成功。

尤其是涉及 OAuth 的 CLI 工具时，只设置 ALL_PROXY 不一定够。很多时候，补齐 HTTP_PROXY 和 HTTPS_PROXY，才是把整条链路真正打通的关键一步。