Codex 实践系列 Vol.01：从跑通 CLI 开始，看懂 Codex 怎么工作

面也会越来越值得关注。目前这个系列的规划是所以作为本系列的开篇我们不聊 Codex 的复杂能力也不做完整评测。只做一件很基础的事在本地把 Codex 跑起来然后让它完成一个边界清楚的小任务。本文任务新手开篇我们只有两个目标跑起来让它做个小东西统计我们的 Codex 余量为什么先从 CLI 开始目前Codex 有几种常见入口CLI、桌面端和 VS Code 插件。桌面端更像一个任务工作台比较适合同时管理多个 Codex 会话的场景。如果你想把不同项目、不同任务分开处理用桌面端会更直观。VS Code 插件更贴近日常编码场景。你可以一边看代码一边让 Codex 帮你解释逻辑、修改代码、补测试。CLI 则更适合做这篇文章里的第一次实践进入一个项目目录启动 Codex发出任务然后直接在终端里观察它读了什么、跑了什么命令、生成了什么结果。所以这一篇我们先从 CLI 开始。在 macOS 上安装 Codex这次我们用的 Homebrew 来安装 Codex安装命令是brew install --cask codex细心的小伙伴可能注意到上面的命令有一个--cask并没有直接写成像是下面这样brew install codex作为一个插曲我们来了解下 Homebrew 里常见两种安装方式。brew install xxx主要用来安装 formula就是 Homebrew 里的命令行软件包。它一般用来安装命令行工具、依赖库等brew install --cask xxx主要用来安装 macOS 应用、预编译程序、插件等Codex 在 Homebrew 里走的是 cask 路线就是一个 macOS 应用所以上面的命令用了brew install --cask codex。装完之后用下面命令查看下版本codex --version如果后面 Codex 提醒你升级或者是你想升级 Codex 版本可以用下面命令来升级版本brew upgrade --cask codex注意这里我没有走 npm 来安装 Codex因为 npm 需要本地先有 Node.js / npm 环境。对我来说在 macOS 上直接用 Homebrew 更省事。实操命令参考图第一次启动安装完成后在终端里运行codex第一次启动时会有登录或授权流程。无脑回车就行如果你是第一次安装运行codex后一般会进入登录 / 授权流程按终端提示完成即可。我这里因为之前已经用过 Codex所以再次启动时没有出现授权页面而是直接进入了会话。如果你在授权过程中遇到了问题可以联系小七帮忙解决。实操前的准备在正式让 Codex 做事之前先注意一件事你在哪个目录里启动 Codex它就会围绕哪个目录工作。所以第一次上手我不建议直接在真实项目里操作。我们先来创建一个干净的练习目录# 创建目录 mkdir codex-usage # 进入到该目录 cd codex-usage实操参考图接下来我们就在这个干净目录里启动 Codexcodex实操参考图启动后你会进入 Codex CLI 的交互界面。使用 Codex 最重要的命令这个时候我们先不急着让 Codex 干活。第一次进来建议先学会一个很重要的命令/status它和 Codex 的使用额度有关。和普通聊天窗口有点不一样Codex 有自己的使用窗口。这里你重点记住两个余量指标5 小时窗口短周期额度适合判断接下来几个小时还能不能继续用1 周窗口长周期额度适合判断这一周整体还剩多少。在 Codex CLI 里查看余量也很简单直接输入/status这个命令会显示当前会话状态其中就包括当前工作目录、模型信息以及 Codex 的使用余量。如果你想把余量常驻显示可以使用/statusline命令来配置细节。实操参考图稍微讲解下这张图其中下面的字段可以重点关注下Model 就是目前使用的模型及相关设置。上图说明模型用的gpt-5.5后面括号里的reasoning medium表示当前推理强度是中间档summaries auto表示策略由系统自动选择Directory当前 codex 所在的目录Permission当前权限模式。上图显示的是Workspace (Ask for approval)可以理解成 Codex 可以在当前工作区里操作但遇到需要确认的动作时会先请求用户批准。第一次上手时这种模式比较适合因为你可以看到它准备做什么再决定要不要让它继续。Agents.md当前目录下有没有AGENTS.md。图里显示none说明这个练习目录里还没有项目规则文件。后面我们会单独讲AGENTS.md它可以用来告诉 Codex 这个项目的结构、规则和限制。Account当前登录的账号和套餐。图里显示的是当前账号敏感信息马赛克了下以及对应的 ChatGPT 套餐。这个信息可以用来确认 Codex CLI 是否已经正确登录。5h limit5 小时窗口的余量weekly limit一周窗口的余量不过/status只能帮我们看到当前状态。如果你想记录自己一天里、这一周里不同时间点的余量变化就需要自己手动保存。所以接下来我们就让 Codex 做一个小工具把每次看到的余量记录到本地。让 Codex 做一个本地余量记录器这里我一开始的想法是能不能做到「每次运行/status就自动把这次的 5h limit 和 Weekly limit 记录到 CSV 里」。这里我们先要来先确认一件事/status是 Codex CLI 交互界面里的命令不一定能像普通 shell 命令一样被外部脚本直接调用。所以这个小任务的第一步不是马上写脚本而是让 Codex 先帮我们验证当前环境里有没有安全、公开的方式拿到这些状态信息。我们直接把下面这段需求发给 Codex请你帮我做一个本地 Codex 余量记录工具。 目标 我希望尽量实现“一次命令完成查看和记录”。也就是说运行 record_usage.py 后脚本会尝试获取当前 Codex CLI 的状态信息解析 5h limit 和 Weekly limit并写入 usage_log.csv同时在终端打印本次余量。 请你先验证当前环境里是否存在安全、公开的方式获取 Codex 状态例如 1. 是否存在 codex status / codex usage 这类命令 2. 是否可以用 codex exec 或其他 CLI 参数拿到 /status 输出 3. 是否可以通过官方支持的方式读取 statusline 或 usage 信息。 要求 1. 不要读取或修改 Codex 的登录凭据、配置文件或缓存文件 2. 不要访问隐藏目录里的 Codex 内部文件 3. 如果无法安全自动获取 status 信息请说明原因并提供一个 fallback 版本 4. 创建 usage_log.csv 5. 创建 record_usage.py 6. 记录 timestamp、5h limit 剩余百分比、weekly limit 剩余百分比、reset 时间 7. 创建 summary.py显示最近一次记录、历史最低余量、余量下降最快的相邻两次记录 8. 全部用 Python 标准库实现不额外安装依赖 9. 最后说明当前实现能自动到什么程度以及还差什么能力才能做到“执行 /status 后自动写入 CSV”。实操参考图这张图里可以看到Codex 接到需求后先说明自己会检查当前目录、可用的codex命令帮助信息只碰公开 CLI 输出不读取隐藏目录或内部文件。这一步挺重要。我们让它做的是一个「余量记录器」但并不希望它为了拿到余量去翻 Codex 的登录凭据、配置文件或者缓存文件。所以 prompt 里提前把边界写清楚不读取或修改 Codex 的登录凭据、配置文件或缓存文件。不访问隐藏目录里的 Codex 内部文件。先验证有没有公开方式比如codex status、codex usage或者codex exec能不能拿到/status输出。这样做的好处是任务一开始就被限制在比较安全的范围里。Codex 可以查公开命令、看帮助信息、写本地脚本但不能为了自动化去碰认证信息。接下来Codex 会继续验证当前 CLI 支持哪些能力。比如它会尝试检查有没有类似下面这样的命令codex status codex usage codex exec实操参考图从图里可以看到Codex 确实在尝试执行这些检查。比如它先试了codex status、codex usage看有没有现成的命令可以直接拿到余量信息然后又查看了codex exec --help、codex doctor --help确认有没有其他可用的非交互方式。这里有一个细节也值得注意它不是一上来就写 Python 脚本而是先判断当前 CLI 有没有现成能力。这个动作很像真实开发里的第一步先看工具链有没有已有接口再决定要不要自己实现。继续往下看这张图里Codex 又尝试了codex help status、codex help usage以及用codex exec去测试能不能拿到当前会话里的/status输出。从返回结果来看目前这些路径并没有直接给出一个稳定、结构化的 status / usage 输出。也就是说我们一开始想要的「执行/status后自动写入 CSV」这件事当前版本并没有一个特别直接的公开接口。这个结果并不算失败。因为它说明我们已经知道了当前版本的边界/status可以在 Codex CLI 交互界面里查看当前余量但要把它变成一个外部脚本可以稳定读取的结构化数据还需要 CLI 提供更明确的输出接口或者后续有官方支持的 status / usage 命令。中间还有一个很值得放出来的截图这张图是 Codex 的命令授权提示。它准备运行一条命令去获取 OpenAI 官方 Codex manual用来确认有没有公开支持的 status / usage 读取方式。执行前Codex 会把命令和原因展示出来并让你确认。这里重点看三部分它要运行什么命令。图里显示的是一条node ... fetch-codex-manual.mjs命令。它为什么要运行这个命令。Reason 里写得很清楚它想联网获取 OpenAI 官方 Codex manual确认是否有公开支持的 status / usage 读取方式。你要不要批准。下面有几个选项Yes, proceed表示只允许这一次Yes, and dont ask again...表示以后同类命令不再询问No, and tell Codex what to do differently表示拒绝并告诉 Codex 换一种做法。第一次使用时我更建议先选第一项只允许这一次。这样既能继续任务也能保留对后续命令的确认。这张图也能说明 Codex CLI 和普通聊天窗口的区别它不只是给你建议而是真的会尝试运行命令。也正因为如此执行命令前看一眼授权提示很重要。回到这次任务本身经过这些验证后结论就比较清楚了当前 Codex CLI 可以在交互界面里用/status查看余量但暂时没有特别直接、稳定的公开方式让外部脚本自动拿到这份/status结构化输出。所以这次任务会进入 fallback 方案。接下来Codex 会开始实现这个 fallback 版本。它会在当前目录里创建几个文件record_usage.py summary.py usage_log.csv其中usage_log.csv用来保存历史记录record_usage.py负责写入一次余量记录summary.py用来查看最近一次记录、历史最低余量以及相邻两次记录之间余量下降最快的一段。过程参考图从这里开始这个小工具就真正落地了。虽然它没有做到「执行/status后自动写入 CSV」但它已经把记录和分析的框架搭好了。后面每次我们查看完/status就可以用这个工具把本次余量记录下来。等记录多了之后再通过summary.py看余量变化。现在我们来运行下 Codex 给我们开发的余量记录脚本python3 record_usage.py我们把 Codex 那边读取到的余量填入到脚本里回车。我们再通过下面的命令来查看下这条记录cat usage_log.csv实操参考图可以看见它把 92% 的百分比变成了纯数字。我们和 C 老师对话几个来回消耗下余量之后再记录几条数据。再运行摘要脚本python3 summary.py它会读取usage_log.csv输出最近一次记录、历史最低余量以及相邻两次记录之间余量下降最快的一段。实操参考图到这里这个很小的 Codex 余量记录器就跑通了。我们可以记录每次余量也可以用 summary.py 查看最近记录、历史最低余量和下降最快的一段。这个任务并不复杂但对于第一篇来说已经够用了。因为它完整走了一遍 Codex CLI 的基础流程提出需求 → 检查当前环境 → 尝试验证已有命令 → 遇到限制后转向 fallback → 创建本地文件 → 运行 Python 脚本 → 生成可检查的结果这个过程比单纯问 Codex「你能做什么」更有价值。因为我们能看到它怎么判断工具能力怎么请求命令授权怎么在当前目录里创建文件也能看到它在发现原始设想走不通时如何转向一个可落地的方案。第一次上手 Codex不一定要做复杂功能。先用一个安全的小任务观察它怎么工作、怎么执行命令、怎么处理限制反而更适合新手。Codex 哪些任务更消耗用量在消耗 Codex 用量来增加记录数据的过程中我问了 Codex 一个问题哪些任务会比较耗你的用量它给的回复是