Codex 桌面应用还是 CLI？从四个处境倒推的选型路径，外加版本口径这个坑

2026-08-09

「我到底该装桌面应用还是用命令行？」这个问题问出来的时候，多数人期待的答案是一张功能对照表。但 Codex（OpenAI Codex）这两个面的差别，真不是「谁功能多」能概括的——官方在快速上手里给的是场景建议，不是能力排名。而且更麻烦的是，官方排查文档里白纸黑字写着：这两个面可能跑在不同版本上，你在 CLI 上见过的东西，桌面应用里可能就是没有。

所以这篇不列大表，改成从你的实际处境倒着推。先说清楚官方口径，再说四个决定性的问题，最后专门讲版本这个坑。

先交代边界：桌面应用、Codex cloud、IDE 扩展我们都没有实测，涉及这三块的一律是官方文档口径，我不会写「我打开后看到……」。本文里凡是标了「本机实测」的，都是在 codex-cli 0.147.0（Windows 11）上跑只读命令得到的结果，我们没有发起过任何模型对话请求。

一、官方自己是怎么分工的

官方文档站把 Codex 分成六个面，各有独立文档页：

面	文档路径
ChatGPT 桌面应用	`/docs/app`
Codex CLI	`/docs/codex/cli`
Codex IDE 扩展	`/docs/codex/ide`
Codex cloud	`/docs/cloud`
ChatGPT Web	`/docs/web`
Codex Remote	`/docs/remote`

快速上手页里给的选择建议只有三句话，但信息量不小：**桌面应用（官方标了「推荐」）**用于项目、本地文件和长时间任务；Web 用于不受打扰的云端复杂任务、免安装；终端和编辑器场景则建议用 Codex CLI 或 Codex IDE 扩展。

读这三句话有个容易走偏的地方：官方给桌面应用加「推荐」，语境是面向所有人的默认入口，不是「开发者也应该优先用它」。后半句专门把终端和编辑器场景拎出来另给建议，这才是给我们这类人看的。

桌面应用的定位，官方写得比较具体：Windows 与 macOS 都可用；可以新建聊天、创建项目，或者直接打开一个文件夹，ChatGPT 会使用你选定位置里的文件与上下文。切换方式官方也点名了两处 UI——在 ChatGPT 里是 composer 上方的 Chat/Work 切换，在 Codex 里从 New chat 开始，右侧有 Quick chat 图标用来问短问题。

二、四个问题，倒推到结论

问题一：这台机器你能装应用吗？

这是最先该问的，因为它可能直接把选项砍掉一半。CLI 的安装方式官方给了四种，Windows 侧是这一条：

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

macOS / Linux 侧是：

curl -fsSL https://chatgpt.com/codex/install.sh | sh

另外还有 npm 与 Homebrew 两条路：

npm install -g @openai/codex

brew install --cask codex
brew upgrade --cask codex

我们本机走的是 npm 全局安装。在 codex-cli 0.147.0（Windows 11）上，codex doctor 的 runtime 行会明确打出这个 codex 是从哪种渠道装的、可执行文件落在哪，install 行给的是 consistent。这一点在「机器上装过好几遍、不知道现在用的是哪个」的时候特别省事——直接看 doctor 这两行，比翻 PATH 快。

如果你在一台受管控的机器上，走用户级的 npm 全局安装通常比装一个桌面应用阻力小。反过来，如果你已经决定要桌面应用，CLI 里有个现成的口子：codex app，官方说明是 “Launch the Desktop app (opens the app installer if missing)“——它会拉起桌面应用，缺失时打开安装器。也就是说这两个面不是二选一，装了 CLI 之后再往桌面走，是一条命令的事。

问题二：这件事要不要被脚本调用？

这是分水岭里最硬的一条。只要答案是「要」，就没得选，必须 CLI。

CLI 有一个专门的非交互子命令 codex exec（别名 e），官方说明是 “Run Codex non-interactively”。它的几个选项决定了它能不能被上游流程吃掉：

--json：事件以 JSONL 打到 stdout
-o, --output-last-message <FILE>：把 agent 的最后一条消息写到文件
--output-schema <FILE>：给一个 JSON Schema 文件路径，描述模型最终回复的结构
--skip-git-repo-check：允许在非 Git 仓库里运行
--ephemeral：不把会话文件落盘
--ignore-user-config：不加载 $CODEX_HOME/config.toml（注意 auth 仍然使用 CODEX_HOME）

位置参数 [PROMPT] 还有个细节：不给参数或者给 - 时从 stdin 读；如果 stdin 是管道并且你同时给了 prompt，stdin 内容会作为 <stdin> 块追加进去。这条决定了你在流水线里怎么拼命令——想把一段日志喂进去当上下文，管道加 prompt 就行，不用自己拼字符串。

同一条逻辑也适用于代码评审。CLI 的 codex review 是 “Run a code review non-interactively”，带 --uncommitted（评审已暂存、未暂存和未跟踪的改动）、--base <BRANCH>、--commit <SHA>、--title <TITLE> 这几个选项，语义都是 Git 层面的，天然适合挂在提交前后。

桌面应用这边，官方文档里没有给出任何非交互能力的说明，没依据的我不编。所以这个问题的结论很干脆：要进脚本、要出结构化产物、要在没人盯着的时候跑，选 CLI。

问题三：你要不要换台设备接着干？

官方对本地与云端的界线有一句很关键的表述：本地工作流在你的设备上运行，云端任务在 OpenAI 托管的环境里运行；桌面应用把 Chat 与 Work 会话放在同一个 ChatGPT 视图里，其中云端 Work 会话跨 web、移动端、桌面端同步，本地 Work 会话只留在你的电脑上。

这句话读起来平淡，实际影响很大：你想「在公司开个头，回家接着看」，那就不是选桌面还是 CLI 的问题，而是这活儿得跑在云端。Codex cloud 的定位是在隔离的云端环境里跑任务、可并行、不占用本地机器，任务入口有 web、GitHub、Linear、Slack 四处，上手三步是登录 Codex、连接 GitHub 账号并选仓库、打开环境设置为仓库创建一个环境；任务结束后可以看摘要与 diff、追加后续要求，或直接开 PR。以上都是官方文档口径，我们没实测。

云端有一条硬约束值得先知道：Codex cloud 自动选择模型，而 gpt-5.6-terra 与 gpt-5.6-luna 在云端不可用。如果你的工作流依赖指定模型，这条得先过一遍。

CLI 侧对云端也开了口子，但要带上阶段标签：codex cloud 在 CLI 帮助里标注为 [EXPERIMENTAL]，子命令有 exec（不启动 TUI 直接提交云端任务）、status、list、apply（把某个云端任务的 diff 应用到本地）、diff（显示统一 diff）。另外还有顶层的 codex apply <TASK_ID>，把 agent 产生的最新 diff 以 git apply 的方式打到本地工作树。EXPERIMENTAL 这个标签的含义就是字面意思——别把它当稳定接口写进团队流程。

问题四：你要多细地控制「它能动什么」？

如果你的需求只是问问题、读读代码，这条不重要。但只要涉及让它改文件，CLI 给的控制粒度是可以写进命令行的。

在 codex-cli 0.147.0 上，-s, --sandbox <SANDBOX_MODE> 的合法取值是 read-only / workspace-write / danger-full-access——这不是我背的，是故意传了个错值试出来的。本机实测执行 codex -s bogus-mode，报错逐字如下：

error: invalid value 'bogus-mode' for '--sandbox <SANDBOX_MODE>'
  [possible values: read-only, workspace-write, danger-full-access]

For more information, try '--help'.

与之配套的是 -a, --ask-for-approval <APPROVAL_POLICY>，三个取值官方释义是：untrusted 只有受信任命令（如 ls、cat、sed）免审批，模型提出不在受信集合内的命令时升级给用户；on-request 由模型决定何时请求审批；never 从不询问，执行失败直接回传给模型。这里有个反直觉的点要提醒：never 说的是不问你，它并不等于放开权限，沙箱该拦的还是拦。

再加上 -C, --cd <DIR> 指定工作根目录、--add-dir <DIR> 追加主工作区之外的可写目录，你就能把「在哪儿干活、能写哪儿、什么时候问我」三件事全部固化在一条命令里，而不是每次靠点击去确认。这是 CLI 在这个维度上最实在的优势——参数是可以被复制、被评审、被写进文档的。

桌面应用侧的对应能力我们没有依据，不比。

三、版本口径：官方排查页点名的那条坑

前面四个问题回答完，你大概率已经落到了「以某一个面为主、偶尔用另一个」的状态。这时候第一个会绊到你的，就是版本。

官方排查页里有一条症状写得很直白：**「功能在 CLI 有、桌面应用没有」，原因是两个面的 Codex 版本不同。**给的处置也很朴素——分别查版本：CLI 用 codex --version；桌面应用在 macOS 上是 /Applications/Codex.app/Contents/Resources/codex --version。

这里必须给本站以 Windows 为主的读者提个醒：官方这条排查项只写出了 macOS 侧的那条路径，Windows 侧对应怎么查，官方没有给出命令。 我也不打算照着 macOS 的路径结构反推一条 Windows 路径填在这儿——那是猜的，猜错了你会对着一个不存在的可执行文件排查半天，比不查更浪费时间。所以在 Windows 上，这条纪律目前只能执行一半：CLI 侧的 codex --version 照常能跑（本机就是在 Windows 11 上跑的），桌面应用侧的版本号，我这里没有可以负责任地交给你的取法。

那 Windows 读者遇到「CLI 有、桌面应用没有」怎么办？至少可以先把已知的那一半坐实：跑一次 codex --version 记下 CLI 的实时版本号，确认你要找的功能在这个版本的 CLI 帮助里确实存在（codex --help、codex <子命令> --help 都是只读的，随便跑）。这一步做完，你手里就有了一个明确的事实：功能在 CLI 的某某版本上有。剩下的差异归因，官方给的方向是版本不同，你不必再往配置文件那边找。

这条为什么值得单拎出来讲？因为它会把人引到错误的排查方向上。你在 CLI 里用惯了某个东西，转到桌面应用发现没有，第一反应通常是「我配置错了」或者「这功能被砍了」，然后开始翻配置文件——方向从一开始就是歪的。官方给的判断顺序是先比版本，两边版本一致再去谈别的。

版本会变这件事，我们本机也撞上了。在同一台机器上，采集开头执行 codex --version 得到 codex-cli 0.131.0，十几分钟后再执行同一条命令得到 codex-cli 0.147.0；全程 which -a codex 只有一个可执行文件，npm 包的 package.json 里 version 也是 0.147.0。Codex 具备自更新能力（features 里有 in_app_updates，配置里有 check_for_update_on_startup，默认 true），所以「我昨天记的版本号跟今天不一样」是正常现象。至于更新过程本身是怎么发生的，我们没观测到，不编。

由此得到一条可以直接执行的纪律：排查任何版本相关的问题，一律以当次 codex --version 的实时输出为准，别用记忆里的版本号，也别用同事截图里的。 顺带一提，特性阶段（stable / under development / experimental / deprecated / removed）也是随版本变的，所以「某功能是什么阶段」这种话必须带版本号才有意义。

还有一个更容易张冠李戴的地方：官方那份排查清单里，大多数条目面向的是桌面应用而不是 CLI——比如侧栏出现不是 Codex 改的文件（原因是项目在 Git 仓库里，面板展示的是全部 Git 状态变更，处置是把 diff 面板切到 “Last turn” 视图）、字体显示异常（在 Settings 面板配置 “Code font”）之类。你在命令行里遇到问题去照着这些条目找，是找不到的。CLI 侧真正好用的第一手工具是 codex doctor。

在 codex-cli 0.147.0（Windows 11）上还试过一个有意思的边界：故意传一段语法不合法的 TOML（codex -c 'features=[unclosed' doctor --summary），命令并没有崩溃退出，doctor 照常跑完，但结果里出现了这一行——

✗ config       config could not be loaded - Fix the reported config error, then rerun codex doctor.

也就是说配置坏掉的时候 doctor 仍然能跑，并且会明确告诉你配置没加载成功。所以「我改完配置怎么没生效」的第一步不是重装、不是换面，而是跑 doctor 看这一行。

四、两个面之间还有哪些接缝

选定主力之后，剩下的是怎么让它们别互相打架。有几处依据明确的接缝：

登录是各面各走各的入口。 CLI 用 codex login（ChatGPT 方式），或者管道传 key：

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

桌面应用的登出界面上，官方点名的两个选项是 “Continue to sign in”（ChatGPT）与 “Sign in another way”（API key）；IDE 扩展是 “Sign in with ChatGPT” 或 “Use API Key”。查当前状态用 codex login status，本机实测输出是一行 Logged in using ChatGPT。凭据要么落在 ~/.codex/auth.json（明文文件），要么进操作系统凭据存储，由 cli_auth_credentials_store 决定（可选 file / keyring / auto，默认 auto）。官方对 auth.json 的原话是当密码看待，别提交、别贴进工单、别在聊天里传——这条无论你主力用哪个面都成立。

配置文件里确实有桌面侧的位置。 本机 config.toml 里存在 [desktop] 段（观测到 appearanceTheme、followUpQueueMode 两个键），配置参考里另有 desktop.custom_file_handlers.<id>.* 系列键。这说明两个面共享同一份用户配置，不是完全隔离的两套东西。

磁盘是共享的，而且不小。 本机 ~/.codex/ 下的 SQLite 日志库单个文件就到了 763 MB，codex doctor 的 Notes 区也提示 rollouts 有 405 个活动文件、占 3.07 GB。这不是哪个面独有的问题，是同一个 CODEX_HOME 攒出来的，值得定期看一眼。

五、一句话版的决策路径

把上面几条压缩一下，按顺序问自己：

要进脚本 / CI / 无人值守 → CLI，用 codex exec 配 --json 或 -o。
要在多台设备之间接着做同一件事 → 这活儿得跑云端（官方口径：云端 Work 会话跨端同步，本地会话只留在本机），CLI 侧对应的 codex cloud 目前标注 [EXPERIMENTAL]。
要精确规定「能写哪里、什么时候问我」 → CLI，把 -s、-a、-C、--add-dir 写进命令。
机器上装不了应用、或者只想先试试 → 先装 CLI（npm 或官方脚本），以后要桌面应用再 codex app 拉起来。
以上都不是刚需，日常就是开个文件夹聊需求、跑长任务 → 官方在快速上手里推荐的是桌面应用，Windows 与 macOS 都可用。

最后再钉一遍那颗钉子：出现「这边有那边没有」先往版本上想，别急着改配置。CLI 侧的版本号随时能用 codex --version 拿到；桌面应用侧官方只给了 macOS 的取法，Windows 上没有对应命令，这半边就先空着，别用猜的路径去填。