服务器上没有浏览器怎么登录 Codex：`--device-auth` 与 1455 端口隧道

2026-08-09

在自己笔记本上装 Codex（OpenAI Codex）的 CLI，登录基本是无痛的：跑一条命令，浏览器弹出来，点两下就完事。换到一台只有 SSH 的云主机、一个容器、或者公司那台连桌面环境都没装的构建机上，同一步就会变成一个死结——ChatGPT 登录这条路，官方文档写得很直白：用 ChatGPT workspace 凭据，在浏览器里完成认证。机器上根本没有浏览器，这一步自然没法走完。

好消息是官方专门给了「无浏览器 / 远程机器登录」这一节，一共三条路。坏消息是这三条路适用的处境完全不同，选错了会白折腾半小时。下面按排查顺序过一遍。

一、先把问题定死在「没有浏览器」上

别一上来就开隧道。远程机器上登录不成，至少有四种可能：真的没浏览器、凭据其实已经有了但你没发现、公司网络的 TLS 代理把握手掐了、配置文件坏了导致整个 config 没加载。判定成本最低的是前两个。

第一条命令，看当前到底登没登录：

codex login status

本机在 codex-cli 0.147.0（Windows 11）上执行这条命令，输出是一行 Logged in using ChatGPT。官方 help 里对它的说明就是「显示登录状态」，本机上它也确实只打印了这一行身份信息；除此之外，它内部还做了什么、有没有联网核对，我们没有依据说明，本文不下结论。你只需要用它回答一个问题：这台机器当前是什么登录身份。如果远程机器上它告诉你已经登录，那你要排查的就不是登录问题，而是别的东西了——直接跳到本文最后一节。

第二条命令，看诊断全景：

codex doctor --summary

本机在 codex-cli 0.147.0（Windows 11）上的输出分成 Notes / Environment / Configuration / Updates / Connectivity / Background Server 几组。跟登录直接相关的有两处：

Configuration 组的 auth 行，本机显示 auth is configured；
Connectivity 组的 network、websocket、reachability 三项，本机 websocket 显示 connected (HTTP 101 Switching Protocols) · 15s timeout，reachability 显示活动的 provider 端点可通过 HTTP 到达。

这两处组合起来能分开两类完全不同的故障：auth 没配好、但 Connectivity 全绿，说明就是认证这一步没走完，属于本文要解决的问题；反过来 auth 显示已配置、Connectivity 却红了，那是网络层的事，跟浏览器无关。

顺带提一句 doctor 的一个特点：本机在 codex-cli 0.147.0（Windows 11）上故意用 -c 'features=[unclosed' 传了一段语法不合法的 TOML，doctor 没有崩溃退出，照常跑完，只是在结果里多出一行 ✗ config config could not be loaded - Fix the reported config error, then rerun codex doctor.。所以配置写坏了 doctor 也能跑，而且会明说没加载成功——这一行如果出现，先修配置，别急着折腾登录。

第三处，翻登录专用日志。 官方说明，登录失败的诊断信息会写在配置的日志目录里的 codex-login.log。日志目录由配置键 log_dir 决定，官方给的默认值是 $CODEX_HOME/log，而 CODEX_HOME 默认就是 ~/.codex。所以多数情况下：

cat ~/.codex/log/codex-login.log

Windows 侧对应位置在你的用户目录下的 .codex\log\ 里，PowerShell 用 Get-Content 看即可。本机在 codex-cli 0.147.0（Windows 11）上确认过 ~/.codex/log/ 这个目录存在（里面有 codex-tui.log），但因为本机登录一直是好的，没有产生过 codex-login.log 的失败内容——这个文件的具体格式我们没有一手样本，这里只给路径，不描述它长什么样。

二、官方给的三条路，怎么选

官方把设备码登录列为首选，另外两条是备选。

路线 A：设备码登录（beta）

codex login --device-auth

然后按提示，在任何一台有浏览器的机器上打开给出的链接，输入一次性验证码。手机也行，笔记本也行——这条路的关键就在于它把「需要浏览器」和「需要跑 Codex 的那台机器」解耦了，两者不必是同一台。

需要说清楚两点。第一，官方文档把这条路标为 beta，别当成完全稳定的功能推到全团队的部署脚本里。第二，本机在 codex-cli 0.147.0（Windows 11）上跑 codex login --help，--device-auth 这一项在 help 里没有任何说明文字——只有选项名。所以它的具体交互细节以官方文档和你当次的实际提示为准，我们没有实测过完整流程，本文不描述它会打印什么。

绝大多数「云主机 / 容器里跑 Codex」的场景，先试这条。

路线 B：从有浏览器的机器上复制已缓存的凭据

官方给的第二条备选，是把一台已经登录好的机器上的凭据拷到远程机器上。

这条路能不能走通，取决于你的凭据到底存在哪儿。官方明确凭据存放位置是两种之一：~/.codex/auth.json 这个明文文件，或者操作系统的凭据存储（keyring / Windows 凭据管理器）。控制这件事的配置键是：

cli_auth_credentials_store = "keyring"   # 可选 file | keyring | auto，默认 auto

判断依据很简单：去源机器上看 ~/.codex/auth.json 在不在。在，说明凭据落在了文件里，复制这条路成立；不在，说明它进了系统凭据存储，你没有文件可拷，这条路对你就是不成立的——别再花时间找了，回去走路线 A。

然后是这条路真正的代价。官方对这个文件的原话是：

“Treat ~/.codex/auth.json like a password: it contains access tokens.”

后半句还有一串明确的禁令：别提交进仓库，别粘进工单，别在聊天里发。这不是客套话——你要做的动作正是「把一个装着 access token 的明文文件搬到另一台机器上」，所以传输通道、目标机器上的文件权限、以及那台机器有多少人有 root，都是你自己要承担的风险。共享的跳板机、多人同用的构建机，我个人不建议走这条。本文也不会给你「这样拷就安全了」的结论。

另外，access token 的有效期不在本文可核实的范围内，所以拷过去能用多久，这里不做任何承诺，以官方说明为准。

路线 C：SSH 隧道转发 1455 端口

官方的第三条：用 SSH 隧道把 localhost 回调端口 1455 转发过去。

理解这条路的关键是搞清楚谁在监听：走浏览器登录时，认证完成后要回调到跑 Codex 的那台机器的 localhost:1455。你的笔记本上有浏览器，但它的 localhost 不是服务器的 localhost，回调就断在这儿了。SSH 本地端口转发正好补上这一段：让笔记本上访问 localhost:1455 的流量，走 SSH 连接落到服务器上去。

在你的笔记本（不是服务器）上开这条隧道：

ssh -L 1455:localhost:1455 <你的用户名>@<服务器地址>

如果你的 Windows 上已经启用了 OpenSSH 客户端，ssh -L 的语法与上面一致；能不能用请自己先跑一下 ssh -V 确认，我们没有在本机验证过这条隧道命令。隧道保持连着，再在服务器那侧的会话里执行登录，认证链接拿到笔记本浏览器里打开。

需要提醒的是：ssh -L 这条是 SSH 的通用写法，不是 Codex 文档给出的命令，我们也没有实测过整条链路——官方给的只是「把 localhost 回调端口 1455 转发过去」这个做法，端口号 1455 来自官方，命令形态由你的 SSH 环境决定。如果你的跳板机禁掉了端口转发（不少企业环境会禁），这条路直接作废，还是回路线 A。

另一条性质不同的路：API key

如果这台机器本来就是跑自动化的，压根不需要绑到某个人的 ChatGPT 账号，那还有一条更省事的：用 API key 认证。官方给的 CLI 侧写法是从管道读：

printenv OPENAI_API_KEY | codex login --with-api-key

本机在 codex-cli 0.147.0（Windows 11）上跑 codex login --help，还看到一个 --with-access-token，官方示例是 printenv CODEX_ACCESS_TOKEN | codex login --with-access-token。

这条路和 ChatGPT 登录不是一回事，选之前要知道两者的账目和权限模型不同：ChatGPT 登录走的是 workspace 凭据，遵循 workspace 的权限、RBAC 与企业留存设置；API key 需要 OpenAI 控制台的 key，按标准 API 费率通过 OpenAI Platform 账户计费。也就是说，换成 API key 之后，账单去向和合规口径都换了一套，团队里这是要跟人确认的事，不是你一个人在服务器上敲条命令就能定的。

写脚本时注意别把 key 写进命令行历史，用环境变量传，示例里一律写 <YOUR_API_KEY> 占位。

三、公司网络那一层：TLS 代理与私有根 CA

有一类失败长得很像「登录不上」，其实是握手在代理上就断了。官方对这种环境给的做法很明确：如果你在有 TLS 代理或私有根 CA 的公司网络里，登录前设置环境变量 CODEX_CA_CERTIFICATE。

export CODEX_CA_CERTIFICATE=<你的根证书路径>

Windows PowerShell 侧：

$env:CODEX_CA_CERTIFICATE = "<你的根证书路径>"

注意「登录前」这三个字——它是给认证流程用的，登录动作已经失败一半再补上去不一定救得回来，把变量设好再重新发起一次登录更稳妥。

四、处置完之后怎么验证

不要靠「好像没报错」判断成功，跑两条只读命令收尾：

codex login status
codex doctor --summary

看两处：login status 是否给出登录身份（本机在 codex-cli 0.147.0（Windows 11）上是 Logged in using ChatGPT，走 API key 的机器输出会不同，本文没有该场景的一手样本，以你当次输出为准）；以及 doctor 的 Configuration 组里 auth 那一行是不是 auth is configured。

顺带说一个方便的点：本机在 codex-cli 0.147.0（Windows 11）上确认，codex doctor --json 的官方说明是 “Emit a redacted machine-readable report”——是脱敏的。所以远程机器上排查不动、要找同事帮忙看时，贴 --json 的输出比截一堆屏更合适。但请注意，「脱敏」是官方对这个输出的说明，不等于你可以把任何目录列表、日志原文随手往外贴；auth.json 的内容任何时候都不要贴。

五、什么情况说明你撞的不是这堵墙

排查最怕一条道走到黑。出现下面这几种迹象，就别在「没浏览器」上继续折腾了：

1. codex login status 已经显示登录成功。 那认证这一环是通的，问题在别处，先看 doctor 的 Connectivity 组。

2. doctor 里出现 ✗ config config could not be loaded。 配置文件本身没加载成功，登录相关的键（比如下面几个）自然也不会生效。先按提示修配置再重跑 doctor。本机在 codex-cli 0.147.0（Windows 11）上验证过，配置坏掉时 doctor 依然能跑完并报出这一行。

3. 你的机器被管控配置盖了登录方式。 官方文档里跟登录相关的配置键有 chatgpt_base_url、forced_login_method（取值 chatgpt 或 api）、forced_chatgpt_workspace_id。如果 forced_login_method 被设成了 api，你再怎么折腾浏览器回调也是白搭；反过来被强制成 chatgpt，那 API key 那条路也走不通。远程机器上装完就登不上，值得先确认一下这几个键有没有被人预置。

# 与登录相关的几个键（组合示例）
cli_auth_credentials_store = "file"
forced_login_method = "chatgpt"

以上为按官方文档键位组合的示例，未逐项实测，以官方文档为准。

4. 你记忆里的版本号和机器上的对不上。 这是个真实存在的坑：本机在同一次采集里，开头执行 codex --version 得到 codex-cli 0.131.0，十几分钟后同一条命令得到 codex-cli 0.147.0，期间 which -a codex 全程只有一个可执行文件。Codex 具备自更新能力（配置里的 check_for_update_on_startup 默认 true）。所以排查任何跟版本相关的问题，都要以当次 codex --version 的实时输出为准，别用记忆里的号。设备码登录还带着 beta 标，跨版本行为变化是完全可能的。

5. 你不确定当前这个 codex 是从哪儿装的。 服务器上常见「装了好几遍，不知道在用哪一个」。本机在 codex-cli 0.147.0（Windows 11）上，codex doctor 的 runtime 行会明确写出安装渠道和可执行文件位置（本机是 npm 全局安装），install 行给出 consistent 的判断。看这两行比一层层翻 PATH 快得多。

最后一句实在话：远程机器上登不上，多数情况先试「设备码登录（beta）」这条官方首选路即可；走不通时，优先怀疑企业网络的证书（CODEX_CA_CERTIFICATE）与管控配置（forced_login_method 一类的键）。真正需要动 1455 隧道的场景不多，但知道回调端口是 1455、以及为什么笔记本的 localhost 到不了服务器，能让你在设备码那条路不通的时候不至于抓瞎。