Codex Cloud 使用指南：环境配置、定价与部署要点

OpenAI 的 Codex Cloud 把编码任务放到由 OpenAI 托管的算力上执行。你只需连接代码仓库、准备一套可复用的环境，然后交给 Codex 一个明确的任务。即便本地笔记本处于休眠状态，Codex 也能自动编辑文件、运行测试；等你回来时审查改动、要求修复，最后发起拉取请求。

本文基于实测与官方文档，梳理从环境搭建到部署衔接的完整流程，并指出定价、资源上限和常见坑点。

Codex Cloud 能做什么

Codex 可以检查仓库、排查缺陷、修改代码并运行项目工具链。一个云环境保存了准备好的仓库、依赖和访问设置，每个新任务都会在独立的工作区中启动。据 Lizard 的实测（Codex CLI 0.159.2，Small Firecracker 沙箱，Node.js 22.23.2），Codex 能够从 lockfile 安装依赖、新增 /healthz 端点，并同时通过新增的 HTTP 200 与原有的 404 两项测试，项目的构建命令也检查了 JavaScript 语法并通过。

这种模式适合可描述、可验证的工作：修复失败的测试、新增 API 端点、更新依赖并确认构建通过。若某项变更需要多轮审查，应在同一个任务中继续，让 Codex 保留工作文件。需要强调的是，这与“远程访问本机 Agent”是两回事——云任务跑在 OpenAI 的机器上，本地关机也能持续执行。

Firecracker 沙箱是 AWS 开源的轻量级虚拟化技术，专为安全多租户场景设计。它同时结合了硬件虚拟化（基于 KVM）的强隔离能力与容器级别的启动速度（毫秒级）和低内存开销（每个 microVM 通常仅需几 MiB 内存）。与传统虚拟机相比，Firecracker 裁剪掉了不必要的设备模拟和 BIOS，只保留运行现代 Linux 工作负载所需的最小功能集。OpenAI 的 Codex Cloud 使用 Firecracker 沙箱为每个云任务创建彼此隔离的执行环境，这意味着即便某个任务中运行的代码存在安全隐患，也无法越界访问其他用户或其他任务的文件和网络资源，是 Codex Cloud 能安全托管多租户编码任务的关键基础设施。

如何配置 Codex Cloud 环境

环境创建需要通过网页版或桌面应用完成，提前准备好 GitHub 仓库、构建说明以及必要的开发凭据。

连接仓库与准备工具链

选择 Work in > Cloud > Select environment > Create environment，按提示连接 GitHub，勾选项目所需的仓库。第一次配置建议挑选一个你熟悉其测试流程的仓库，这样便于对照云端结果。

Codex 会自动检查项目、安装依赖与工具、验证工作流。若项目依赖特定运行时版本，需要主动说明。例如针对 Node.js 项目，可以要求它“按项目指定的 Node.js 版本与包管理器，从 lockfile 安装依赖，识别测试与构建命令并运行二者，逐条报告命令与结果”。配置过程会记录 Install script（依赖安装）与 Start skill（服务启动与就绪检查），涉及数据库或私有包仓库时尤其要仔细核对这些命令。

发布环境与提交任务

审查配置报告、解决失败项后保存并选择 Publish，等到 Environment published 提示出现再启动任务。这里有个容易混淆的细节：保存只存储配置，发布才会把准备好的文件系统固化为新任务的起点，而共享权限又是另一项独立设置——三者不能混为一谈。

启动任务时，一次只给一个有明确验收标准的改动。例如为 Web API 仓库添加 GET /healthz 端点，要求返回 HTTP 200 与 {"status":"ok"}，同时新增测试并运行既有测试套件，展示命令、结果与变更文件。仅靠一个 HTTP 响应无法证明整个应用正常，因此验收标准中必须保留既有测试。

审查结果

接受改动前先读 diff 与测试输出，确认 Codex 真的执行了它声称的命令、测试覆盖了目标行为，并留意被跳过的检查与无关的文件改动。在同一任务中要求修正，再提交或发起 PR，合并前仍需跑常规 CI。

lockfile（锁定文件）是现代包管理器生成的文件，记录了项目中每个依赖包的确切版本、下载地址和内容哈希值。常见例子包括 Node.js 的 package-lock.json、Python 的 poetry.lock 或 Pipfile.lock、Rust 的 Cargo.lock。与 package.json 这类只声明语义化版本范围（如 ^1.2.0）的清单文件不同，lockfile 确保任何人、任何机器在任意时间安装依赖时得到的都是完全相同的版本组合。在 Codex Cloud 的语境中，从 lockfile 安装意味着云端环境与开发者本地环境之间的一致性可以得到保证，从而避免"本地能跑、云端失败"这类难以排查的问题。配置环境时务必确认项目已提交 lockfile，并让 Codex 按 lockfile 而非版本范围来安装。

环境与任务文件的生命周期

环境提供起始配置，任务在启动后累积自己的改动。启动新任务会从已发布的配置获得独立工作区；恢复同一任务则延续该任务已保存的文件与未提交改动；编辑并重新发布环境只会更新新任务的起点，已存在的任务保持各自状态。

OpenAI 文档说明，最后一次交互开始或恢复任务后，已保存的 VM 状态默认有最多七天的恢复窗口。这是 VM 恢复窗口，不是持续执行的承诺，也不是对话历史保留期。重要工作务必提交到 Git。若在任务中临时安装了某个工具，只对当前任务有效；要让它进入未来任务，需要编辑环境、验证安装并重新发布。

定价与用量限制

云聊天包含在符合条件的 ChatGPT 套餐中。据 OpenAI 公布的价格，Plus 为每月 20 美元，Pro 为每月 100、200 或 500 美元，Business 按年计费为每用户每月 20 美元（需两人以上），按月则为 25 美元，Enterprise 与 Edu 需联系销售。Free 与 Go 在定价指南中有有限的桌面版 Codex 访问权限，选择套餐前应确认云功能资格。

订阅价格无法可靠换算为固定的云任务数量——模型选择、任务长度、上下文与工具调用都会影响消耗。本地消息与云聊天共享套餐额度，ChatGPT Work 也与 Codex 共享用量。本地消息的估算并非云任务配额，请以用量仪表盘显示的剩余额度与重置时间为准，符合条件的套餐可购买额外额度。另外，API Key 为基于 API 的 Codex 工作流单独付费，不包含 Codex Cloud 功能。

服务与密钥的访问配置

私有包仓库既需要网络访问，也需要有效凭据——只放行主机名只解决了网络那一半问题。当前环境设置区分两种供值方式：环境变量用于程序需要直接读取实际值的场景；网络密钥用于凭据应通过代理送达已允许的 HTTPS 服务。使用网络密钥时，程序拿到的是占位符，代理会在匹配目标域名、经 443 端口 HTTPS 请求时替换为真实凭据。务必在配置阶段测试一次请求。

若下载失败，检查具体 URL——包仓库与其下载主机可能需要分别加入白名单；若认证失败，检查凭据、作用域与目标地址。开发凭据应严格限定在任务所需的服务范围内。

网络密钥（Network Secrets） 与普通环境变量的核心区别在于凭据是否对运行中的程序可见。使用环境变量时，代码通过 process.env.XXX 直接读取到的就是明文凭据，任何能访问该进程的代码（包括第三方依赖或潜在恶意代码）都可能将其外泄。网络密钥则采用代理注入模式：程序读取到的是占位符，当发出目标域名的 HTTPS 请求时，OpenAI 管理的代理拦截该请求并在 443 端口将其中的占位符替换为真实凭据后转发。这意味着即使凭据泄露了占位符，攻击者也无法还原真实值，且代理可限定凭据只能发往已允许的目标域名。对私有包仓库、内部 API 或云服务凭据，优先使用网络密钥是更安全的选择。

任务前需检查的资源上限

云环境指南列出的默认资源因套餐而异：Plus 与 Edu Plus 为 2 vCPU、8 GiB 内存、8 GiB 磁盘；Pro、Business、Enterprise 以及 Edu、Edu Pro 为 4 vCPU、16 GiB 内存、32 GiB 磁盘。Enterprise 客户可咨询更大的 VM。运行会下载大依赖或产出大构件的构建前，先检查磁盘占用。

同一指南中，新的云环境体验暂不支持计算机与浏览器操作、GitLab 与自托管 GitHub Enterprise Server；仓库技能可用于任务，但本机个人技能不会自动同步。若验收测试需要浏览器交互，应单独准备具备浏览器能力的测试环境——通过的单元测试无法证明渲染后的按钮真的可用。

为什么有些指南描述不同行为

OpenAI 仍为既有审查与集成工作流保留 Codex Cloud (Legacy) 文档，较早的说明可能描述仅用于配置的密钥或容器缓存。上述流程请使用新的云环境设置，应用旧说明前先确认对应的是哪套体验。

Codex Cloud 与 Codex CLI 的区别

CLI 是你可以运行在自己电脑或远程机器上的界面，Cloud 则提供 OpenAI 托管的工作区；CLI 也能向 Cloud 提交任务。从终端操作云任务时，可用 codex cloud、codex cloud exec --env YOUR_ENVIRONMENT_ID "..." 与 codex cloud list --limit 5 等命令，具体参数以已安装 CLI 的 --help 为准。提交命令只负责启动云端工作，结果仍需后续检查。

云任务之后：部署衔接

接受改动后，应用仍需要部署目标，也可能需要浏览器来验证渲染效果。一个务实的顺序是：审查 Codex Cloud 的 diff，经常规检查合并，再把该 commit 部署到目标平台。此时应用与数据库作为独立资源运行，开发沙箱停止后仍可继续。

若自行搭建 Agent 工作流，沙箱方案通常提供 shell、文件与 HTTPS 预览，desktop 模板还会附带带浏览器的桌面。需要注意的是，在自己可控的基础设施上运行 Codex CLI，意味着你要自行管理凭据、进程生命周期与保存的工作，并按 OpenAI 相应条款为模型用量付费——这类基础设施不会为你的 Codex Cloud 额度增加容量。

常见配置问题速查

问题	优先检查
云控制项缺失	登录账号、套餐、所选工作区与管理员访问设置
GitHub 已连接但缺少仓库	GitHub 权限以及为环境选中的仓库
配置失败	配置对话中第一条失败命令，修复后重跑检查
依赖下载失败	确切的仓库与下载主机名，再看认证
新任务仍缺少已安装的工具	是否更新并重新发布了可复用环境
未提交文件似乎丢失	是否重新打开了原任务，而非启动新任务

改动配置后，务必从重新发布的环境启动一个新任务验证效果。

小结

Codex Cloud 的价值在于把“可描述、可验证”的编码工作放到托管算力上后台执行。真正决定成败的不是模型能力本身，而是环境是否可复现、验收标准是否包含既有测试、以及你对七天 VM 恢复窗口与套餐额度边界的清醒认知。把重要改动及时提交 Git，把临时工具沉淀回可复用环境，才能让这套工作流稳定运转。