安装 Codex CLI，验证版本、路径与登录

安装器说成功，终端却可能在运行另一个 Codex

一台使用很久的电脑，可能同时留下 npm、脚本安装和旧 shell 配置。你再次安装，终端依然命中旧路径；画面没有报错，环境却并不可信。

CLI 是否装对，要看新终端里的解析路径、版本和真实只读任务。 我们先记录现场，再选择一个安装来源。

这节课要交付什么

这不是一份只需要读完的功能介绍。你要在真实但可控的环境中留下一个可以复查的结果，并且能回答三个问题：Codex 看到了哪些事实，它实际做了哪些动作，你用什么独立证据确认结果成立。

最终结果是：一份可复现的 CLI 安装记录和通过验证的第一个只读会话。开始前先创建一份简短记录，把当前环境、目标、禁止动作和验收方式写下来。后面的命令、截图和修改都回到这份记录，不靠聊天窗口里的“应该已经好了”判断完成。

先看官方边界

当前官方 CLI 页面为 macOS、Linux 和 WSL2 提供安装脚本，并以进入项目目录后运行 codex 作为起点；官方 GitHub 仓库同时记录 npm 包入口。教程不把第三方镜像、未知的一键脚本或管理员权限当默认方案。安装命令会变化，复制前要再次核对官方域名与页面。

官方页面会随产品更新。教程引用的是当前可核对的能力与命令，不把界面位置、套餐权限或预览功能包装成永久承诺。你在自己的设备上看到不同按钮时，先核对官方页面和本机版本，再决定是否继续；不要用过期截图覆盖现场事实。

任务现场

终端里输入 codex，系统可能显示 command not found，也可能命中了旧版本。两种情况都不能靠“再装一次”解决：前者常是 PATH，后者可能是多个安装来源并存。你需要先记录 shell、操作系统、which codex 的结果和现有版本，再选择唯一安装路径。

先把现场写成四行：工作目录或项目、当前版本或输入、允许动作、完成证据。如果其中任何一行只能写“让 Codex 自己看”，说明上下文仍然不够具体。Codex 可以帮助检查，但不能替你决定哪些数据能上传、哪个生产动作已获授权，或一个异常是否可以忽略。

动手前准备

新建 cli-install-record.md，记录 uname 或系统版本、当前 shell、which codex、node/npm 是否存在。macOS/Linux/WSL2 优先从官方 CLI 页面复制当前安装命令；若团队明确采用 npm，再从官方 GitHub README 核对包名。不要把 token、cookie 或完整环境变量写进记录。

把练习放在可恢复的位置，保留原始输入，并记录开始时的状态。涉及代码时先看版本控制状态；涉及数据时先复制脱敏样例；涉及外部服务时先使用只读或草稿模式。准备工作看似慢，却能让失败变成一次可以解释和回退的实验。

第一步：只读建立基线

安装前运行 which codex || echo "codex not found"，若已有结果，再运行 codex --version 并记录路径。确认来源后只执行一种官方安装方法。完成后打开一个新的终端窗口，再次检查 which codex 和 codex --version；新窗口能排除当前 shell 临时状态造成的假成功。

这一阶段不要急着要求“直接修好”。先让 Codex 复述目标、列出它实际读取的来源，并指出还缺哪些证据。你要检查它有没有打开正确目录、有没有把搜索摘要当原文、有没有把旧日志误当当前状态。基线不可信，后面的修改越多，返工成本越高。

第二步：限制范围后执行

进入一个只含 README 的练习目录后运行 codex，选择官方支持的登录方式。首次请求写：‘只读告诉我这个目录是什么、有哪些文件、README 的第一条规则；不要修改或运行项目脚本。’随后使用 /status 检查会话与工作目录，需要时用 /permissions 确认当前权限。

执行指令应该同时包含目标、范围和停止条件。把“不要乱改”换成可观察边界，例如只允许修改两个文件、不安装依赖、不发送消息、不触碰生产数据。出现新的权限、需要改变既有契约或发现输入口径不一致时，要求 Codex 停下来报告，而不是自行选择更大的方案。

第三步：用独立证据验收

退出 CLI，再使用 codex resume 恢复会话，核对它仍然对应练习目录。检查 README 哈希或版本控制状态没有变化。最后记录安装来源、解析路径、版本、登录方式、项目路径和一次成功的只读输出；这些是以后升级或排错的基线。

验收必须尽量脱离生成答案本身：安装类任务看版本、路径和真实启动结果；界面任务看目标视口与交互；数据任务用独立计算和异常清单；安全任务用原始复现、补丁 diff 与回归测试。把通过、失败和未验证分开记录，未验证不是失败，但绝不能伪装成通过。

完整案例

阿杰的 Mac 上 npm 全局目录与官方脚本目录都存在。他先发现 which codex 指向旧 npm 路径，版本落后。没有直接覆盖安装，而是确认团队不依赖旧版本，移除冲突来源后按当前官方页面安装。新终端中路径唯一，版本正确；只读任务复述了 README 规则，git status 为空。这个记录比“安装成功”的截图更能解释环境。

案例的重点不是复制同一句 prompt，而是观察决策顺序：先确定权威来源，再缩小动作面，最后让证据闭环。如果你的项目结构不同，保留这个顺序，替换文件名、命令和验收对象。任何会产生外部影响的步骤，都应在真正执行前再次获得明确授权。

故障诊所

command not found 时先看 which、PATH 和 shell 启动文件，不要用 sudo 反复安装。登录失败时保留可公开的错误码与时间，检查网络和账号可用性，不粘贴凭据。版本没有变化时比较多个 codex 路径和新旧终端。若 WSL 中命中 Windows 可执行文件，回到 WSL 的 which 结果与 CODEX_HOME 设计，明确宿主再继续。

恢复时一次只改变一个变量。先保存错误原文和当前状态，再判断问题属于安装路径、权限、上下文、实现还是验收环境。不要连续重装、重写和切换工具，因为那会抹掉因果关系。修复后重复最小复现，再跑相邻路径，确认没有用一个新问题遮住旧问题。

迁移练习

模拟一次升级：先保存当前版本与路径，再按官方页面执行更新方式，打开新终端核对版本，恢复旧会话并运行同一只读检查。把任何差异写入 upgrade-record.md，并说明如果升级失败怎样回到可用状态。

完成练习后，把其中的产品名和文件名遮住，只保留“输入—动作—证据—停止条件”。如果这四项仍能指导另一个任务，说明你学到的是方法；如果离开示例 prompt 就不会继续，回到任务现场，补出你真正依赖的判断规则。

以后升级时，先比较路径再比较功能

把 which codex、版本、安装来源、登录方式和练习目录保存下来。升级后先重复这些检查，再判断产品行为变化。

如果问题只能靠反复重装暂时消失，它还没有被解释。可复现的环境记录，才是 CLI 真正的起点。

完成检查

• 只保留一个明确的 CLI 安装来源
• 新终端中的路径和版本符合预期
• 安装与排错过程中没有暴露凭据
• 只读会话能够退出、恢复并保持正确目录
• 我保留了开始状态、实际动作和最终证据
• 我把失败、未验证和已通过分开记录
• 需要新权限或外部影响时，Codex 会停下来询问