第二步：只读检查版本、帮助与认证状态

版本与帮助用来确认当前设备的命令能力。login status 核对当前认证方式；处于已登录状态时退出码为 0，但这不等于工作区权限、用量和后续请求都正常。若后面才报错，另记发生时间与错误阶段，不要把它重新归入“浏览器打不开”。

不要为了搜集材料直接打印整个环境变量列表。只读命令的结果也需要检查，分享时只保留必要的脱敏摘要。

第三步：核对远程或无头设备的登录条件

假设 CLI 在远程 Linux，浏览器在自己的电脑。网页完成授权后，远程终端还在等。此时最有用的记录是“终端与浏览器不在同一台设备，回调尚未确认”，而不是“会员没生效”。这是虚构示例，没有使用真实用户登录记录。

对这类环境，官方提供设备代码认证 beta。前提是个人账号已在安全设置开启，或工作区管理员已开放权限；确认可用后，可在运行 CLI 的终端发起：

这条命令会启动认证，完成后建立登录状态，与前面的只读检查不同。按本次流程显示的官方地址与一次性代码操作，不复用旧回调链接，也不把一次性代码交给别人。没有相关权限时，先找管理员确认可用方式。

第四步：生成脱敏的支持记录

有用的材料包括系统、CLI 版本、是否远程、最后完成阶段、脱敏错误与时间。完整回调 URL、令牌和 auth.json 不应出现在文章、聊天、工单或仓库里；它们不能当作普通日志附件。

重新尝试之前先写一行预期，例如“这次核对设备代码登录是否已开放”。尝试后补一行实际结果，保留仍未确认的部分。这样第二个人接手时，也能看懂问题停在哪里。

我把阶段表、脱敏模板与边界说明整理在 Codex 登录卡住排查清单。本次只核对官方资料，未在真实账号中完成登录流，与 OpenAI 无官方隶属关系。