Codex全面上云了，但真正值钱的不是“电脑可以关机”

这次 OpenAI DevDay 把 Codex Cloud 又往前推了一大步。

不少录友看到“Codex 上云”，第一反应是：

不就是把 Agent 放到远程服务器跑吗？

如果只是这样，那真不算什么新东西。2025 年的 Codex 云端任务已经能离开本地电脑执行，代码仓库拉下来，任务跑完，再把结果交回来。

但那套体验有一个很烦的问题：每次任务都像临时住酒店。

重新拉代码、装依赖、配工具、补环境变量。项目越复杂，Agent 真正写代码之前浪费的时间越多。

这次最关键的更新，是中间多了一层 Reusable Environment，可复用开发环境。

不是简单把电脑搬到了云上，而是把一套能工作的开发环境，变成了可以反复启动的项目资产。

一、以前是一次性虚拟机，现在是“环境”和“任务”分开了

现在的 Codex Cloud 可以提前准备这些东西：

• GitHub 代码仓库
• 项目依赖和运行时版本
• Linter、格式化工具、测试工具
• 安装脚本和启动 Skill
• 环境变量、网络密钥和允许访问的域名

Codex 会先检查仓库，尝试安装依赖、启动服务、跑测试。缺什么，它会在配置阶段问你。

等这套环境真正跑通后，再发布成一个可复用环境。

后面新开任务，不需要每次从一台空机器重新折腾。新任务会直接从已经发布的环境起步。

这里最容易误解的一点是：环境复用，不等于所有任务挤在同一个目录里乱改。

OpenAI 把两层拆开了：

• Environment 负责提供稳定起点：仓库、依赖、工具、权限和配置
• Workspace 负责承载单次任务：代码修改、临时工具、测试结果和未提交文件

这张图回答的是：Codex Cloud 到底复用了什么，又隔离了什么。左边的仓库、依赖和权限先被准备成一套可复用环境；右边每个任务从同一个起点启动，却各自在独立 Workspace 里修改代码、跑测试和做安全扫描。环境可以共用，任务状态不能互串。

所以，同一个环境可以连续启动多个任务，但每个任务仍有自己的工作文件。

这套设计解决的是两个互相冲突的问题：准备环境要快，任务之间又不能互相污染。

二、可复用环境为什么比“云主机”更重要

很多人低估了 Agent 启动成本。

一个稍微真实点的项目，可能要指定 Node.js 版本、安装 pnpm、拉私有包、启动数据库，再执行迁移和测试。

如果每个任务都从零准备，Agent 还没改一行业务代码，时间和额度已经先烧掉一截。

更麻烦的是，临时安装经常不稳定。

今天依赖源超时，明天系统包版本变了，后天某个启动命令又需要人工补一句。你以为自己在派发开发任务，实际每天都在重复修环境。

Reusable Environment 的价值，就是把“这项目到底怎么跑起来”先验证一次，再让后面的任务复用这个答案。

Agent Coding 真正想规模化，不能只复用 Prompt，还要复用可执行环境。

三、任务不是跑完就没了，最长可以恢复7天

云端开发最怕什么？

不是慢，而是任务做到一半，环境没了。

现在已有任务会保留自己的文件状态，包括未提交修改和任务里临时安装的工具。官方文档写得很明确：默认情况下，任务保存的虚拟机状态在最后一次开始或恢复任务后，最长可恢复7天。

这意味着你可以在电脑上发任务，出门后用手机看结果，晚上再回到同一个任务继续改。任务在云端运行，本地电脑关机也不影响它干活。

但卡哥还是得提醒一句：

7天恢复不是版本控制。

重要改动该 Commit 就 Commit，该推远程仓库就推远程仓库。别把云端任务状态当 Git 备份，到了第八天才想起来找代码。

四、Plus和Pro拿到的云端机器不一样

按照 OpenAI 当前文档，默认云端任务配置是：

ChatGPT套餐	vCPU	内存	磁盘
Plus、Edu Plus	2	8 GiB	8 GiB
Pro、Business、Enterprise	4	16 GiB	32 GiB
Edu、Edu Pro	4	16 GiB	32 GiB

普通前后端项目，Plus 的配置能跑起来。

但如果仓库很大、依赖安装重、测试并行度高，或者要同时启动多个服务，2 核 8G 很容易卡住。这个时候不要第一时间怪模型笨，先看任务是不是在编译、内存或者磁盘上撞墙了。

模型负责想，机器负责跑。机器不够，Agent 再聪明也只能等。

国内录友如果卡在 ChatGPT 会员付款，可以直接看这篇：国内ChatGPT充值教程2026：支付宝微信开通Plus全方案。充值方式这里不单独展开。

五、怎么把一个项目真正搬进Codex Cloud

别一上来就扔一个大需求。先把环境跑通。

整个流程并不复杂：

1. 在 Codex 新任务里选择 Work in > Cloud
2. 打开环境选择器，创建新的 Environment
3. 连接 GitHub，并选择需要检出的仓库
4. 让 Codex 检查运行时、依赖、工具和启动方式
5. 补齐环境变量、网络权限和必要密钥
6. 检查安装结果，确认测试和服务能正常运行
7. 发布环境，再从这个环境启动真正的编码任务

我建议第一次只让它做三件事：安装依赖、启动项目、跑通测试。

这三步稳定了，再开始派业务需求。

否则安装失败、网络没放行、密钥缺失和代码 Bug 会混在一起。最后你只看到“任务失败”，根本不知道是哪层出了问题。

六、本地、Worktree、Cloud到底怎么选

Codex 现在不是只有一种工作方式。

模式	文件在哪里	最适合什么任务	主要代价
Local	当前本地目录	快速查看、直接改手头项目	会碰当前工作区，本机必须在线
Worktree	本机独立 Git 工作树	并行改代码，又不想污染当前分支	依赖本机环境和磁盘
Cloud	云端独立 Workspace	长任务、后台执行、跨设备继续	要先配好仓库、网络和密钥

卡哥的判断很简单：

• 十分钟内能完成的小改动，留在 Local
• 要并行开几条开发线，用 Worktree
• 安装、测试、扫描要跑很久，或者你准备关电脑，交给 Cloud

别为了“上云”而上云。云端最值钱的场景，是任务能离开你的电脑继续推进。

七、Codex Security Cloud也来了，但它不是自动背锅侠

这次一起出现的，还有 Codex Security Cloud。

它可以连接 GitHub 仓库，在云端发起扫描、整理发现、验证问题，并准备修复补丁。官方把它放在 research preview 阶段，定位已经不只是“帮我看一次代码”，而是逐渐变成持续盯仓库的安全 Agent。

这条路是对的。

现在 Agent 生成代码太快，人工 Review 很容易跟不上。安全扫描如果还只放在发布前跑一次，问题会越积越多。

但扫描结果依然需要人判断。权限、业务逻辑、误报和修复副作用，不会因为它叫 Security Cloud 就自动消失。

Agent 能把问题找得更早，不能替团队承担上线责任。

八、先别把云端Codex想成“远程版万能电脑”

有三条边界必须说清楚。

第一，云端任务不会自动拿到你本地的文件、正在运行的进程、浏览器登录状态和 VPN。缺什么服务，要在云环境里单独配置。

第二，当前 OpenAI 官方文档仍把 Computer Use 和浏览器操作列在云环境暂不支持的能力里。桌面端 Codex Record & Replay 能做的事，不代表 Cloud 全都能做。

第三，仓库里的 Skills 可以给云任务使用，但你电脑上的个人 Skills 不会自动同步过去。团队真正依赖的规则和技能，最好跟仓库一起维护。

这也是为什么我更愿意把 Codex Cloud 看成一台受控的远程开发机，而不是另一台完整复制你电脑的 Mac。

写在最后

Codex 上云最值得关注的，不是“可以关电脑”。

而是仓库、依赖、工具和权限终于能沉淀成一套可复用环境，任务再从这套环境里各自隔离运行。

环境先跑通，权限收紧，重要代码及时提交。

这样云端 Agent 才是生产力，不是另一台需要你天天救火的电脑。

资料来源

• OpenAI Codex Cloud environments：https://learn.chatgpt.com/docs/environments/cloud-environments
• OpenAI Codex environments：https://learn.chatgpt.com/docs/environments/modes
• OpenAI What's new：https://learn.chatgpt.com/docs/whats-new
• OpenAI Codex Security Cloud setup：https://learn.chatgpt.com/docs/security/setup