登录这种事，平时毫无存在感，一旦卡住就能让人一晚上干不了活。前阵子深夜，一位做后端的同行发消息给我，说他的 Codex 突然登不上了——终端里敲完命令，浏览器弹出来转了两圈又跳回一个空白页，命令行那边就干等着，最后甩出一行红字。他以为是账号被封，差点去重新注册。我让他把屏幕截图发过来，一眼就看出来：本地时间比标准时间慢了十几分钟。改完时间同步，问题当场消失。类似的情形我这两年遇到过太多次，Codex 登录不上这件事，表面上都是"登不上"，底下的原因却天差地别：有的是本地凭据文件损坏，有的是浏览器插件把回调页拦了，有的是公司机器上环境变量把配置目录指到了奇怪的位置，还有的是账号席位被管理员回收。这篇就把我处理这类问题的完整思路摊开讲，从怎么给故障分类，到认证链路到底怎么走，再到一层一层往下排查的具体命令和参数，最后附一张能直接对着查的速查表。刚上手的新手能照着步骤走通，已经用了一段时间、偶尔被卡住的老手也能从里面找到几条省时间的排查捷径。

1. 先别急着重装，把故障归类再动手

1.1 从"卡在哪一步"反推问题域

遇到登录失败，最忌讳的动作就是上来就卸载重装。重装能解决的问题其实很少，但会把现场证据全部清掉，本来五分钟能定位的事，最后变成盲猜。我习惯的第一个动作是先问自己：这次失败具体卡在认证链路的哪一环。Codex 这类命令行 AI 编码工具的登录，本质是一次标准的授权码流程，可以拆成四段：客户端发起请求并拉起浏览器、你在浏览器里完成身份确认、浏览器把授权结果回传给客户端、客户端拿授权码去换长期凭据。卡在第几段，指向的原因完全不同。

如果命令敲下去浏览器压根没弹出来，或者弹出来的是个错误页，那问题在第一段，多半是客户端版本、默认浏览器设置、或者命令行环境把打开浏览器的动作吞掉了。如果浏览器里正常显示登录页面，但你输入账号密码后一直转圈、或者提示"服务暂时不可用"，那问题在第二段，属于服务侧或账号侧。如果你在浏览器里明明看到了"授权成功"字样，切回终端却还是失败，那问题在第三段，是最常见的本地回调问题——端口没监听上、被拦截、或者回传的地址和客户端期望的对不上。如果终端提示的是"凭据无效""刷新失败"之类，那问题在第四段，通常是本地存储的旧凭据坏了或者过期了。

这套四分法我用下来命中率很高，因为它把"登不上"这个模糊描述变成了一个可以定位的位置。你只要记住一句口诀：看浏览器有没有正常走完，看终端有没有收到结果。两个"有"和"没有"的组合，一共四种情况，对应四个不同的排查方向，比漫无目的地试要快得多。

1.2 一张症状对照表，先缩小范围

光靠回忆容易记混，我把这两年攒下来的典型症状整理成了一张表，你可以直接对着自己的报错文案找最接近的那一行。注意表里的"优先动作"是建议的第一步，不是唯一解法，但按这个顺序试，绝大多数情况在前两步就能解决。

这张表的价值不在于全，而在于帮你把"我感觉它坏了"变成"它大概是哪一类坏了"。我在帮别人远程看问题的时候，第一句话基本固定是："把终端里最后三行报错原文发我。"报错文案是最诚实的线索，比任何描述都准。很多人会凭印象说"就是登不上"，但把原文贴出来一看，关键词立刻就把范围缩到了某一行。

1.3 动手前的三个前置检查

真正开始折腾本地环境之前，有三件事必须先确认，否则后面所有操作都可能是在错误的前提上打转。

第一，确认账号本身是活的。用同一个账号在浏览器里打开官方控制台，看看能不能正常进入、有没有席位、有没有待处理的验证步骤。这一步只要两分钟，却能排掉相当一部分"其实是账号侧变了"的情况。我遇到过好几次，用户以为是客户端坏了，实际是团队管理员调整了席位分配，账号被移出了可用名单，客户端无论怎么重装都登不上。

第二，看一眼服务状态页。这类云服务偶尔会有区域性波动，登录接口恰好在那几分钟不稳定。状态页上如果挂着"部分用户登录受影响"的公告，你要做的只是等，而不是把本地环境折腾一遍。这一点很多人会忽略，因为它违背直觉——我们总倾向于认为是自己这边出了问题。

第三，把客户端版本号记下来。在终端里执行版本查询命令，把输出抄到记事本上。认证流程的细节在不同版本之间改过不止一次，老版本可能还在用已经被服务端下线的旧接口，表现就是"明明账号密码都对，就是登不上"。版本号还有一个用处：万一最后要走工单，这是必填信息。

注意：这三步做完再动手，不要边查边改。改到一半忘了原始状态，后面就很难判断是哪一步起了作用。

2. 认证链路拆开看：一次登录到底发生了什么

2.1 授权码流程的三段式，用办卡打个比方

很多人排查登录问题效率低，根本原因是对流程没有概念，只能靠试。我把这套流程比作去银行办一张卡：你走进大厅（客户端发起请求），柜台核对你的身份并给你一张回单（浏览器完成身份确认，拿到授权码），你拿着回单去另一个窗口换实体卡（客户端用授权码换长期凭据）。三个环节缺一不可，而且回单是有时效的、一次性的——过期了要重新排队，用过了也不能再用第二次。

对应到技术上，客户端启动登录时会做三件事：生成一个带随机值的授权请求、在本地回环地址上起一个临时监听端口、把授权地址交给系统默认浏览器打开。浏览器完成身份确认后，会把授权码拼在回调地址上跳回那个本地端口，客户端收到后立刻拿它去换取长期凭据，随即关闭端口。整个过程通常几秒钟内完成。

理解了这个结构，很多"玄学"现象就有解释了。比如"我点了授权，浏览器显示成功，但终端没反应"——这说明第三段的路被堵住了，客户端的监听端口没收到回调，最常见的是端口被别的程序占了，或者浏览器跳转时被某个安全插件拦截在了本地回环地址上。再比如"我十分钟前试过一次失败了，现在重新试还是报授权码失效"——因为第一次的授权码已经被消费或过期，必须从头发起一次全新流程，直接在旧页面上刷新是没用的。

2.2 凭据存在哪里，什么时候会失效

登录成功之后，客户端会把拿到的长期凭据写到本地的一个配置文件里，路径通常遵循各平台的惯例：macOS 在用户库的 Application Support 下，Linux 在 XDG 配置目录下，Windows 在 AppData 的 Roaming 目录下。文件名各家叫法不同，但基本都是 JSON 格式，里面有访问令牌、刷新令牌、过期时间戳这几项。

这里有个关键点值得说清楚：访问令牌是短命的，刷新令牌才是长久之计。访问令牌一般只有几十分钟到几小时的有效期，过期后客户端会自动拿刷新令牌去换一张新的。你平时感觉不到这个过程，是因为它在后台静默完成了。但只要刷新这一环出问题——比如刷新令牌本身过期了、或者被服务端作废了、或者本地文件被改坏了——表现就是"昨天还好好的，今天一开就让我重新登录"。

我在实践中总结出一条判断经验：如果报错出现在启动瞬间、且提示是凭据相关，那九成是本地那份文件的问题，而不是你操作错了。这时候正确的动作是把它清掉重新走一遍完整登录，而不是反复重试登录命令。反复重试反而容易触发频率限制，让本来简单的问题变复杂。

另外提醒一句，那份文件里存的是能直接换取访问权限的东西，等同于密码。不要随手把它提交到代码仓库，不要在聊天工具里截图分享，也不要用同步盘把它同步到多台机器上——多机共用一份凭据很容易互相干扰，后登录的把先登录的挤掉，表现就是两台机器轮流掉线。

2.3 浏览器里已登录，不等于客户端已登录

这是个高频误解。"我浏览器里明明是登录状态，怎么命令行还说我没登录？"——因为这是两套完全独立的会话。

浏览器里的登录状态存在浏览器的 Cookie 里，作用范围是网页端；客户端的登录状态存在本地那个配置文件里，作用范围是命令行。两者唯一的交集是那一次授权跳转：网页端确认"这个人是谁"，然后把结果交给客户端，客户端自己存一份。存完之后，两者就各走各的了，你清浏览器 Cookie 不会影响客户端，你把客户端凭据删了浏览器也照样是登录状态。

还有一种更隐蔽的情况：浏览器里登录的是 A 账号，但你其实想用 B 账号。很多人电脑上同时挂着个人账号和工作账号，登录页直接复用了默认会话，一路点"继续"就授权了，等回到终端发现项目权限不对才反应过来。所以如果你的账号不止一个，登录前先确认浏览器当前处于哪个账号的会话，或者干脆开一个干净的浏览器配置窗口来走这一步。这个坑我踩过，当时排查了半小时客户端，最后发现授权给的是另一个账号。

3. 逐层排查：从最便宜的检查开始

3.1 第一层：系统时间和时区，最容易被忽略的元凶

把时间检查放在第一位，是因为它成本最低、命中率却不低，而且症状极具迷惑性——所有东西看起来都对，账号对、密码对、浏览器也对，就是登不上。

原理不复杂：授权流程里传输的凭据带有签发时间和失效时间，服务端在验证时会拿本地时间和凭据里的时间戳做比对，并允许一定的偏移容差，业界常见是五分钟（300 秒）。如果你的机器时间和标准时间差了十几分钟，那么请求里的时间戳在服务端看来要么是"来自未来"，要么是"早就过期"，两种情况都会被直接拒绝。报错文案里常常带not yet valid、expired、clock之类的词。

具体怎么算差异，我给你一个直观的推演：假设你的机器慢了 12 分钟，也就是 720 秒；服务端此刻是 12:00:00，你的机器认为是 11:48:00；客户端发起刷新请求时打上的时间戳是 11:48:00，服务端一算，这个时间戳比当前时间早了 720 秒，超过了 300 秒的容忍窗口，于是判定这次请求无效。反过来机器快了 20 分钟，服务端会看到一张"20 分钟后才生效"的凭据，同样拒绝。这就是为什么慢和快都会出问题。

排查命令按平台来：

# macOS / Linux：看本地时间、UTC 时间和时区设置 date date -u timedatectl status 2>/dev/null || systemsetup -gettimezone

# Windows PowerShell：看本地时间与时间同步服务状态 Get-Date Get-TimeZone w32tm /query /status

如果发现偏差，处理方式很简单：把系统的自动时间同步打开，或者手动点一次"立即同步"。Windows 可以用w32tm /resync，macOS 在日期与时间设置里勾选自动设置，Linux 上sudo systemctl restart systemd-timesyncd或对应的服务。同步完成后再查一次date -u，和标准时间对照，误差控制在几秒内就可以放心重试登录了。

注意：如果你在虚拟机、容器或双系统机器上工作，休眠唤醒后时间漂移是常事，这类环境建议把时间同步设为开机自启，省得每次都要手动修。

3.2 第二层：清掉本地那份坏掉的凭据

时间没问题，下一步就动本地凭据。这一步的核心原则是：先备份观察，再删除重登。直接删掉你就失去了分析样本，万一重登还是失败，连对比的依据都没有。

先定位目录。路径里通常带产品名，各平台惯例如下，把尖括号部分换成你实际看到的目录名：

# macOS ls -la "$HOME/Library/Application Support/<产品目录>/" ls -la "$HOME/Library/Preferences/" | grep -i <产品名> # Linux / WSL ls -la "${XDG_CONFIG_HOME:-$HOME/.config}/<产品目录>/"

# Windows PowerShell Get-ChildItem "$env:APPDATA\<产品目录>" -Force Get-ChildItem "$env:LOCALAPPDATA\<产品目录>" -Force

找到之后先做两件事：一是看文件修改时间，判断是不是最近被动过；二是把整个目录打包一份到临时位置。然后执行清理——注意清的是配置目录里的认证相关文件，不要整个目录一锅端，有些设置项（比如默认模型、快捷键）重配起来也很烦。

# 备份后清理认证文件（文件名按实际目录内容替换） mkdir -p ~/backup-codex-auth cp -a "$HOME/.config/<产品目录>/." ~/backup-codex-auth/ 2>/dev/null rm -f "$HOME/.config/<产品目录>/auth.json" rm -f "$HOME/.config/<产品目录>/credentials.json"

清完之后重新执行登录命令，看流程能不能完整走通。这一步能解决掉相当一部分"昨天好好的今天不行"的情况，原因通常是凭据文件在异常退出时被写坏了，或者磁盘写满导致写入了半截内容。

有一个细节我要专门提一下：配置目录可能不可写。有些机器上这个目录属于管理员或另一个用户，你以普通用户身份运行，客户端读得到但写不进去，表现就是"每次登录都成功，但下一次打开又要重新登录"。检查方法很简单，登录成功后立刻ls -la看文件修改时间有没有更新，没有更新就是没写进去。权限问题用chown或icacls修一下即可，别用sudo硬跑整个客户端——那样会把文件属主改到 root，后面问题更多。

3.3 第三层：浏览器这一侧到底拦了什么

前面说过第三段最容易出问题：浏览器要跳回本地回环地址把授权码交回去，这一跳被拦，整个流程就断在这里。拦截来源主要有三类。

第一类是浏览器扩展。广告拦截、脚本拦截、隐私保护类扩展，很多默认规则会把对本地回环地址的跳转当成可疑行为处理。排查办法是开一个无痕窗口试一次——无痕模式下大部分扩展默认不启用。如果无痕能成，那基本就锁定了是扩展问题，再逐个关掉试，找到具体是哪个。我遇到过最常见的是那种"增强隐私保护"类的扩展，它连本地跳转都拦，日志里还不显示，特别费时间。

第二类是浏览器的默认设置。比如默认浏览器指向了一个根本没装的程序，客户端调用打开浏览器时静默失败，终端就在那儿干等。还有的情况是浏览器被设成了"每次询问"，弹出的确认框被忽略了。这类问题的特征是：终端有反应，但浏览器窗口始终没出现，或者出现了但页面内容是空的。解决办法是不要依赖自动拉起，直接把终端里打印出来的那条链接复制到浏览器地址栏手动打开。

第三类是本地端口的问题。客户端起监听端口时如果撞上了已被占用的端口，浏览器跳过去会显示"无法访问此网站"或"连接被拒绝"。具体现象很好认：地址栏是127.0.0.1:加一串数字，页面打不开。查占用很简单：

# macOS / Linux：查谁占了这个端口（把 1455 换成你地址栏里的端口） lsof -nP -iTCP:1455 -sTCP:LISTEN

# Windows：查端口占用及对应进程号 netstat -ano | findstr :1455 tasklist /FI "PID eq <上一步查到的PID>"

找到占用进程后，能关就关（常见占用者是本地开发服务器、调试工具、另一个还在等待回调的客户端实例），关不掉就换个方式登录。绝大多数这类工具都留了手动粘贴授权码的后路：浏览器跳转失败时，地址栏里那串code=后面的值就是授权码，把它复制下来粘贴回终端的提示符，效果和自动回调完全一样。这条后路我在各种受限环境下用过很多次，非常可靠，值得记住。

3.4 第四层：终端环境变量和配置文件在捣鬼

这一层排查的人最少，但踩中的概率不低，尤其是在配过一堆开发环境的机器上。

先说环境变量。客户端找配置目录时会读环境变量，如果你在某个项目里为了隔离设置过指向自定义目录的变量，那个变量可能被写进了 shell 的启动脚本，之后每次打开终端都生效，而你自己忘了。表现就是"配置文件明明在这里，客户端却说没登录"——因为它读的是另一个目录。查一下当前 shell 里所有相关变量：

# 查看与产品相关的环境变量 env | grep -i codex env | grep -i -E 'home|config'

如果发现某个变量指向了一个意料之外的路径，那就是它了。临时验证的办法是在当前会话里unset掉再登录，成了就说明确实是变量的问题，再去启动脚本里把那一行改掉或加条件判断。另外HOME、XDG_CONFIG_HOME这类基础变量被改过也会引发同样的问题，顺手一起看。

再说配置文件本身。不少工具有一个全局配置文件（YAML 或 TOML 格式），里面除了模型、温度之类的参数，还可能写着认证方式。如果这个文件里被手动填了一个错误的认证方式或一段过期的值，那么优先级通常会压过交互式登录，表现就是"登录命令执行成功，但下次用还是提示未认证"。打开看看有没有和认证相关的键，有就先把那几行注释掉再试。

还有一种情况是环境变量和配置文件打架：命令行参数优先级最高，其次是环境变量，最后是配置文件。你从高到低逐层确认，就能找到是谁把正确值覆盖了。

注意：改这类启动脚本和配置文件前先复制一份。排查到一半忘了原来写了什么，回滚都难，我在这上面浪费过一整晚。

3.5 第五层：账号本身是不是变了

本地全查完还是不行，就得回到账号侧。这一步需要的信息只有你自己能确认，我把常见情况列一下。

席位与订阅。团队版或企业版的席位由管理员分配，被回收之后客户端会立刻失去授权，而且报错往往很含糊，只给一个 401，看不出是席位问题。确认方式是登录管理后台看自己的状态。

二次验证。开启了二次验证但没完成绑定，或者验证器的时间漂移导致验证码一直不对，都会卡在浏览器那一段。这里又绕回到时间同步——验证码基于时间生成，本地时间错了，算出来的码永远是错的。

组织的访问策略。有些团队会限制只有特定域名下的账号才能使用，或者要求先通过某个审批流程。这时候浏览器里可能一切正常，客户端也能完成授权，但换凭据时被拒。这类情况只能找团队管理员确认，本地怎么折腾都没用。

账号别名与登录方式不一致。同一个邮箱可能绑定了多种登录方式，你这次用的是 A 方式，之前授权的是 B 方式，服务端看是两个身份，凭据自然不通。这个坑比较隐蔽，特征是"有时候能登有时候不能"，取决于你点了哪个登录按钮。

确认完这五项还是不行，那就该怀疑是不是服务侧的问题了，回到状态页看一眼，或者换个时间段再试。

4. 特殊场景：远程机、容器和多账号环境

4.1 远程开发机和容器里，回调根本回不来

这是我在实际工作中遇到最多的一类。你在远程服务器或容器里执行登录命令，客户端试图拉起浏览器——服务器上没有浏览器；或者它起了本地端口，但那个端口在你本机的浏览器里根本访问不到。表现就是命令执行后卡住不动，超时后报一句很含糊的错。

正确的做法是一开始就不要走自动回调，直接用手动模式。常见的有两种：一种是设备码方式，命令执行后终端给出一串短码和一条链接，你在本机浏览器打开链接、输入短码确认，服务器那边就会自动完成登录；另一种是直接打印授权链接，你在本机浏览器打开、授权完成后，把跳转地址里的授权码复制回终端粘贴。两种方式都能绕开回环地址不可达的问题。

# 设备码方式（具体参数名以实际版本帮助信息为准） codex login --device-code # 或者先看帮助，确认当前版本支持哪些登录参数 codex login --help

如果你在容器里工作，还要额外注意一件事：容器的文件系统可能是临时的。今天登录成功，容器一重建，凭据文件跟着没了，明天又要登一次。解决办法是把配置目录挂载成持久化卷，或者干脆在宿主机上登录，然后把整个配置目录以只读之外的方式映射进去。我一般选前者，因为挂载卷能保证文件属主和权限不出问题。

还有一种容易忽略的：远程机上的系统时间。云端实例从休眠中恢复、或者宿主机的时钟服务异常，都会导致时间漂移，症状和本地完全一样，但你不会想到去查一台"刚开机"的服务器的时间。远程排查时我养成了一个习惯，登上去第一件事就是date -u，五秒钟的事，省掉后面半小时的猜谜。

4.2 多账号多项目，怎么避免互相踢下线

同时维护个人项目和工作项目的人，几乎都会遇到这个问题：两个项目用不同账号，结果来回切换，每次切都要重新登录，烦到想砸键盘。

根因是默认情况下所有实例共用同一个配置目录，凭据只有一份，谁最后登录谁生效。解法是给每个账号（或每个项目）分配独立的配置目录，通过环境变量在进入项目时切换。这样两份凭据物理隔离，互不覆盖。

# 在两个不同的 shell 会话里，分别指向独立的配置目录 export CODEX_HOME="$HOME/.config/codex-work" codex login # 另一个终端 export CODEX_HOME="$HOME/.config/codex-personal" codex login

为了避免每次都手敲，可以写进 shell 的启动脚本，用目录判断自动切换：

# 放进 ~/.zshrc 或 ~/.bashrc，按项目目录自动选配置 if [[ "$PWD" == "$HOME/work/"* ]]; then export CODEX_HOME="$HOME/.config/codex-work" else export CODEX_HOME="$HOME/.config/codex-personal" fi

这套做法的额外好处是便于清理：某个环境的凭据出了问题，直接把对应的目录删掉重登，不会影响另一个环境。我现在的机器上常驻三个配置目录，两年下来没再出现过互相踢下线的情况。

4.3 换机器之后，凭据别直接搬

换电脑时最省事的想法是把配置文件拷过去，我不建议这么干，原因有三个：一是凭据可能和机器标识有绑定，拷过去也用不了，还可能触发风控让原机器的凭据一起失效；二是两份相同的凭据同时使用，容易互相刷新覆盖，最后两边都登不上；三是万一旧机器的凭据已经泄露或被作废，你等于把问题一起搬了过来。

正确姿势是新机器上老老实实走一遍完整登录，然后在旧机器上把配置目录清理掉。整个过程五分钟，比事后排查两小时划算得多。

如果确实需要在新机器上快速恢复工作环境，值得搬的是非敏感配置：模型偏好、快捷键、项目路径映射、自定义提示模板这些东西。我一般会把这些抽到一个单独的文件里，跟认证文件分开管理，这样换机器只搬这一份，认证部分永远走重新登录。

最后补一个小技巧，关于"登录成功了但用不了"。有时候登录流程显示成功，但一发请求就报权限错误。这时候别急着重新登录，先确认三件事：当前配置目录是不是你以为的那个（用env | grep确认）、凭据文件是不是刚被更新过（看修改时间）、以及项目级配置里有没有覆盖认证设置。这三条查完，基本就能定位到底是登录没生效，还是生效了但被别的东西挡了。

5. 速查表与踩坑实录

5.1 高频问题速查表

排查到最后，我习惯把结论沉淀成一张能直接查的表。下面这张是我这两年实际处理过的案例汇总，按"现象 → 根因 → 处理"三段式排列，遇到问题时从上往下扫，找最像的那一行。

用表的时候有个小提示：别只看和自己症状最像的那一行，也扫一眼相邻的行。因为登录失败经常是多因叠加，比如时间偏差加上端口占用同时存在，你修好一个以为解决了，实际还差一步。我吃过这个亏，改完时间以为万事大吉，结果还是失败，白高兴一场。

5.2 我踩过的几个坑，说给你听

第一个坑：用管理员权限跑登录命令。当时在一台权限管得很严的机器上，普通用户执行登录命令老是写不进去，我图省事直接加了提权。登录确实成功了，但凭据文件的属主变成了管理员，之后用普通用户跑就再也读不到了。更麻烦的是，后面再想用普通用户登录，因为它读不到那份文件又写不进去，陷入死循环。最后是把整个配置目录的属主改回来才解决。教训是：能用权限修复解决的，就不要用提权绕过去。

第二个坑：在无痕窗口里登录完了又关掉窗口。有次排查扩展拦截问题，用无痕窗口走通了授权，我以为是验证成功就完事了。实际上后来发现，那次授权给的是无痕会话的临时身份，正常窗口里还是未登录状态，而客户端那边因为拿到过一次凭据，表现得很像"登录成功了"，直到几小时后刷新失败才暴露。现在我的做法是：无痕窗口只用来验证是不是扩展问题，验证完立刻回到正常窗口重新走一遍完整流程。

第三个坑：同时开两个终端重试。卡住的时候人容易急，一个终端没反应就在另一个终端再敲一遍。结果两个登录流程同时在进行，各自起了监听端口，浏览器的回调被其中一个抢走，另一个永远等不到，两个都失败，还额外触发了一次频率限制。现在我给自己定了规矩：同一时间只允许有一个登录流程在跑，卡住就先按 Ctrl+C 干净地退出来，再重新开始。

第四个坑：把凭据目录放进了同步盘。早年间为了多机方便，我把整个配置目录放进了自动同步的文件夹。结果两台机器同时在线时，凭据文件被来回覆盖，登录状态一天掉好几次。这个问题的隐蔽之处在于，你不知道是同步导致的，只会觉得"这个工具怎么这么不稳定"。后来改成每台机器独立登录，问题立刻消失。

5.3 走工单之前，把这几样东西准备好

折腾到最后还是解决不了，就得走官方支持渠道了。这一步的效率取决于你带了多少信息。我见过很多人只写一句"登录不上"，来回沟通三四轮才开始真正排查，时间全浪费在补信息上。

我会准备的清单是这样的：客户端版本号（版本查询命令的原样输出）、操作系统与版本、完整的报错原文（不是复述，是复制粘贴，包括前面几行看起来无关的日志）、问题发生的时间点与你的时区、已经试过哪些排查动作以及结果（这一项最能体现你自己做过功课，也帮对方跳过基础检查）、是否在受限网络或容器环境中运行。

获取详细日志的方式通常是给命令加详细输出参数，把标准错误一并重定向到文件：

# 抓取登录过程的详细日志，注意日志里可能含敏感信息，提交前检查一遍 codex login --verbose > /tmp/login-out.log 2> /tmp/login-err.log tail -n 50 /tmp/login-err.log

注意：日志里可能包含邮箱、令牌片段、内部路径等信息，提交前把敏感部分打码。这一点很多人会忽略，直接把原始日志贴到公开渠道。

还有个小建议：把排查过程按时间顺序写下来，哪怕只是三行。"14:02 执行登录，浏览器授权成功，终端无响应；14:05 查端口 1455 被占用；14:08 关闭占用进程后重试成功"——这样的记录比一段大段描述有用得多，也方便你下次遇到类似问题时快速对照。

我个人在实际操作中的体会是，Codex 登录不上这件事，八成以上的情况根本不需要重装客户端，问题都出在四个地方：本地时间、本地凭据、浏览器回调、配置目录指向。把这四个位置做成固定检查项，遇到问题按顺序过一遍，通常十分钟内就能定位。真正需要重装或者需要官方介入的比例非常低。所以下次再卡住的时候，先深呼吸，别急着卸载，从date -u开始敲起。