Codex IDE 扩展和 CLI 该怎么分工？从你的处境倒推一条决策路径

2026-08-09

同事问得最多的一句是「Codex（OpenAI Codex）到底装 IDE 扩展还是用命令行」。这个问题不好直接回答，因为它默认了两者是替代关系。实际情况更像是：官方把 Codex 铺在六个使用面上，你的处境决定了哪几个面对你有意义，而不是哪个面更强。

先说清楚这篇的证据边界

这点必须放在最前面，否则后面的话没法读。

本文里凡是标注「本机实测」的，都来自 codex-cli 0.147.0（Windows 11）上执行的只读命令——--help、doctor、features list、sandbox 跑无害命令、故意传错参数看报错。我们没有发起过任何模型对话请求。

而 Codex IDE 扩展、ChatGPT 桌面应用、Codex cloud，我们一次都没有实测过。涉及这三块的内容，本文一律写「官方文档给的做法是……」，不会告诉你界面上哪个按钮在哪。这也是我不打算写「IDE 扩展功能对比表」的原因：没有依据的维度，不比。

那这篇还能给你什么？能给的是：CLI 侧那些可以逐条验证的边界条件——沙箱、权限、非交互执行、认证方式——以及官方文档自己划出的分工线。选型的绝大部分决定权，恰恰落在这些边界条件上。

官方自己是怎么分面的

先看官方文档站的六个分面，这是判断的起点：

使用面	文档路径
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 扩展。

注意最后这句的措辞——官方把 CLI 和 IDE 扩展并列放在同一个推荐位上，没有在两者之间再分高下。所以「哪个更强」这个问题，官方文档层面就没有答案。真正能分出高下的，是下面这几问。

第一问：这活儿要不要在无人值守的情况下跑完

这是分界最清楚的一条，也是我建议第一个问的。

如果你要的是「提交一段指令，让它跑完，把结果落到文件或管道里，后面接别的程序」——比如 CI 里跑一轮评审、批量处理一批仓库——那就是 CLI，而且是 codex exec。本机实测的帮助文本里，这个子命令的官方说明就是 “Run Codex non-interactively”。它自带的这几个选项，决定了它能不能接进你的流水线：

codex exec --json --skip-git-repo-check -o result.txt "你的指令"

--json：事件以 JSONL 形式打到 stdout。具体有哪些字段我们没有采集，别指望我在这里给你字段名；但「是 JSONL 事件流」这一点是 help 里写明的，意味着你可以逐行解析，不必等整个进程结束。
-o, --output-last-message <FILE>：把 agent 的最后一条消息写到文件。想要一个干净的结论文本，用这个而不是去 grep 日志。
--skip-git-repo-check：允许在非 Git 仓库里运行。临时目录、下载下来的一坨代码，没这个选项会被拦。

还有两个在自动化里很有用：--ephemeral 不把会话文件落盘；--output-schema <FILE> 接一个 JSON Schema 文件，描述模型最终回复的结构。

反过来，如果这活儿本身就需要你一句一句看着改、随时插话，那非交互模式没有意义。这时 CLI 的交互式界面、IDE 扩展、桌面应用之间的差别就退化成了纯粹的习惯问题——你平时手放在哪里，就用哪个。这不是和稀泥，是我确实没有依据说 IDE 扩展在交互体验上强于或弱于 CLI。

第二问：要不要让它改本地文件

要改本地文件，就绕不开沙箱和审批，而这两块在 CLI 上是可以逐条验证、逐条收紧的。

CLI 的 -s, --sandbox 只有三个合法取值。这不是我记的，是本机实测故意传错参数逼出来的报错——在 codex-cli 0.147.0（Windows 11）上执行 codex -s bogus-mode：

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

官方标注 workspace-write 是默认模式，释义是 agent 可以读文件、在工作区内编辑、在这个边界内跑常规本地命令。想让它只看不动，用 read-only。

这里有个高频误解，值得单独拎出来：审批策略 -a, --ask-for-approval 的 never 档，官方释义是「从不询问，执行失败直接回传给模型」——它改变的只是要不要问你，沙箱边界还在。真正撤掉边界的是 danger-full-access，或者那个名字已经把话说尽的 --dangerously-bypass-approvals-and-sandbox（官方原文写的是 “EXTREMELY DANGEROUS. Intended solely for running in environments that are externally sandboxed”）。把 never 当成「放开权限」，是我见过最容易出事的一个理解偏差。

如果你只是想在不撤沙箱的前提下多给一个可写目录，有 --add-dir <DIR>，配置侧对应 sandbox_workspace_write.writable_roots。

这一问的结论是：凡是「我需要精确控制它能碰什么」的场景，我倾向于 CLI，因为每一档的取值都能在命令行上写死、能复现、能写进脚本让全组统一。IDE 扩展侧的设置我们没有实测，官方有一页 Codex IDE extension settings（/docs/developer-settings?surface=ide），要配就去看那页，别照搬 CLI 的选项名。

第三问：你有没有管理员权限

这条对 Windows 用户是硬约束，很多人是在装完之后才发现的。

官方文档说明，Windows 上的沙箱是在 PowerShell 中原生运行的，强制文件系统与网络的边界，不需要 WSL、不需要虚拟机。它有两种模式：

模式	官方口径
`elevated`	官方标注为首选；使用专用的低权限沙箱用户，文件系统权限边界加防火墙规则；需要管理员批准的初始化设置
`unelevated`	回退方案；用从当前用户派生的受限 Windows token 运行命令，基于 ACL 的边界，用环境级离线控制替代防火墙规则；官方自己写明保护更弱

配置键是 windows.sandbox = "unelevated" | "elevated"。另外有个硬性要求：winget 必须可用。

所以如果你在一台受管控的公司电脑上，UAC 提示点不出来、本地用户创建被阻止，官方给的排查顺序是：① 重启 Codex ② 重试 elevated 初始化 ③ 需要时回退到 unelevated ④ 发送诊断，日志在 CODEX_HOME/.sandbox/sandbox.log。还有一个具体错误值得记住——错误 1385，官方原文是 “Windows is denying the logon type the sandbox user needs.”，含义是沙箱用户已经建出来了，但策略不允许它执行命令。官方在这一条上只给了上面那四步，我不会替你编注册表或组策略的改法。

顺带说，Windows 版本本身也有支持梯度：Windows 11 推荐，较新的 Windows 10（v1809 及以上）是尽力而为，更老的 Windows 10 不推荐。

这一问怎么用：如果你的机器连 elevated 初始化都过不去，那么「让 agent 在本机大改文件」这条路本身就要打折扣，此时更该考虑的不是「换个 IDE 扩展试试」，而是第四问——把这类任务挪到云端去。

第四问：要不要云端

官方对 Codex cloud 的定位是：在隔离的云端环境里跑任务，可以并行，不占用本地机器。任务发起入口有 web、GitHub、Linear、Slack；上手三步是用 ChatGPT 账号登录、连接 GitHub 并选择可访问的仓库、打开环境设置为仓库创建一个环境。任务结束后可以看摘要与 diff、追加要求，或者直接开 PR。这些全部是官方文档口径，我们没有实测。

云端有两个限制会直接影响选型，都是官方明说的：

模型由 Codex cloud 自动选择，你不像在 CLI 上那样用 -m, --model 指定；
gpt-5.6-terra 与 gpt-5.6-luna 在云端不可用。

还有一条本地与云端的界线也要记住：云端的 Work 会话跨 web、移动端、桌面端同步，本地的 Work 会话只留在你自己的电脑上。指望换台机器接着干，就得走云端。

CLI 这边有对应的入口：codex cloud，帮助文本里标注为 [EXPERIMENTAL]——这个阶段标签必须带上，别当稳定功能推。它的子命令有 exec（不启动 TUI 直接提交云端任务）、status、list、apply、diff。

三个接缝：这些面不是二选一

前面几问都在划界，但真正好用的用法是把面接起来。本机实测的帮助文本里，有三处明确的接缝：

codex apply <TASK_ID>——顶层子命令，官方说明是把 agent 产生的最新 diff 以 git apply 的方式打到你本地的工作树。也就是说：云端跑、本地落地，是官方设计里就有的路径。
codex app——官方说明 “Launch the Desktop app (opens the app installer if missing)“，从命令行把桌面应用拉起来。
codex --remote <ADDR>——把 TUI 连到远端的 app server，接受 ws://host:port、wss://host:port、unix://、unix://PATH，配套的 --remote-auth-token-env <ENV_VAR> 用来指定装 bearer token 的环境变量名（只给变量名，不要把 token 写进命令行）。需要提醒的是，app-server 与 remote-control 这两个子命令在帮助文本里都标了 [experimental]。

一个必踩的坑：两个面的版本可能不一样

这条我单独列，因为它能解释掉一大类「玄学问题」。

官方排查页明确写了一个症状：功能在 CLI 上有、桌面应用上没有，原因就是两个面的 Codex 版本不同。官方给的查法是分别查：CLI 用 codex --version，桌面应用（macOS）用 /Applications/Codex.app/Contents/Resources/codex --version。

而 CLI 自己的版本也是会动的。本机采集时有一个很实在的观测：同一台机器，开头执行 codex --version 得到 codex-cli 0.131.0，十几分钟后再执行同一条命令得到 codex-cli 0.147.0，期间 which -a codex 全程只有一个可执行文件。所以排查任何版本相关的问题，都要以当次 codex --version 的实时输出为准，别用你记忆里的版本号，更别用别人博客里的。

同理，codex features list 里某个特性显示 experimental 还是 stable，也是随版本变的。这也是为什么本文所有实测结论都写死了「codex-cli 0.147.0（Windows 11）」。

第五问：账号与预算走哪条线

这一问其实不分 IDE 还是 CLI，但很多人是在这里卡住的。

官方给的认证方式有两种：ChatGPT 登录，用 ChatGPT workspace 凭据、浏览器完成认证，遵循 workspace 权限、RBAC 与企业留存设置；API Key，需要 OpenAI 控制台的 key，按标准 API 费率通过 OpenAI Platform 账户计费。

各面的入口不一样。CLI 用 codex login，或者管道传 key：

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

官方文档给的做法是，IDE 扩展在登出界面选 “Sign in with ChatGPT” 或 “Use API Key”，桌面应用则是 “Continue to sign in” 或 “Sign in another way”。这几个界面元素我们没有实测，只是照抄官方文档的名字。

在 codex-cli 0.147.0（Windows 11）上，codex login status 的输出是一行 Logged in using ChatGPT——想确认自己当前走的哪条线，跑这一条就够了。凭据存在 ~/.codex/auth.json（明文文件）或操作系统的凭据存储里，配置键是 cli_auth_credentials_store，可选 file / keyring / auto，默认 auto。官方对 auth.json 的原话是把它当密码看待，别提交、别贴进工单、别在聊天里发。

订阅这边只提与「哪个面能用」直接相关的一行：Plus 档 $20/month，官方说明里 Codex 覆盖 web、CLI、IDE、iOS（ChatGPT 官方定价页，2026-08-09 核对，以官方为准）。也就是说，选面这件事本身不需要额外付费。另外官方公告过一个限时活动：限时内 Codex 包含在 ChatGPT Free 与 Go 中，并且 Plus、Pro、Business、Enterprise、Edu 的速率上限翻倍，更高上限在 app、CLI、IDE、cloud 四个面上都适用——这是限时活动，不要当成常规权益来规划。

什么情况下这套分工不适用

最后说几条别硬套的：

你要的是「哪个面写代码质量更高」——这篇答不了，我们一次模型对话请求都没发过，任何关于输出质量的比较都是编的。
你在 macOS 或 Linux 上——沙箱是三套完全不同的机制：macOS 用系统内置的 Seatbelt，Linux/WSL2 需要用包管理器装 bubblewrap（bwrap），Windows 是原生受限 token。上面第三问里 Windows 的排查顺序，一步都不要往 Linux 上套。
你想比 IDE 扩展的具体命令与设置——官方有独立页（Codex IDE extension commands / slash commands、Codex IDE extension settings），去看那两页；我们没实测，不给二手描述。
团队统一规范的场景——如果目标是让全组的沙箱档位、审批策略、可写目录一致，CLI 的可复制性是实打实的优势，因为这些都能写成一行命令或一段配置发下去。但也别指望一份 CLI 配置能同时管住其它面，我们没有依据支持这个说法。

顺带给一个查文档的小技巧：官方文档站任何一页的 URL 后面加 .md 后缀就能拿到 Markdown 版本；站点还提供 llms.txt（完整页面索引）与 llms-full.txt（合并全文）。选型时与其信别人的对比表，不如把这两个文件喂给你手头的 AI 工具，让它按你的处境筛一遍。