Codex 云端环境学习体验：把开发带离办公桌

2026 年下半年，我越来越觉得，Cloud Agent 正在进入加速落地的阶段。我的期待也越来越具体：一项工作交出去以后，Agent 有没有合适的 Environment，能不能保存 Task state，能不能在受控的 authorization 下调用服务，再把结果交回来。

对我来说，最直接的价值是不用每次有个开发想法，都得回到办公桌前，打开电脑。项目和 toolchain 在云端准备好后，我可以从手机上交代工作，让 Agent 修改实现、运行测试，再回来检查结果、补充要求。电脑合上以后，工作仍然能继续。

Codex Cloud 的两处体验尤其值得记一笔：Environment provisioning 可以通过对话推进，缺少什么就继续补充、验证；Network Secret 则让项目调用 API 时，尽量不必持有 raw credential。前者降低了把项目准备好的成本，后者处理了 Agent 获得服务访问能力时的一道信任边界。

本文记录个人使用体验，产品信息核对日期为 2026 年 10 月 15 日。讨论对象是当前支持对话式 Environment 配置、Network Secrets 和 Personal Vault 的 Codex Cloud；Legacy 环境的 Credential 机制有所不同。示例与工程分析会在对应位置说明适用范围。

1. 工作如何继续：手机、dot 与 Cloud Task

Codex Cloud 为开发 Task 提供 remote execution environment。Agent 在里面编辑文件、运行命令、调用项目工具，再交回改动和检查结果。同一个 Cloud Task 可以从网页、手机和桌面端继续，个人电脑休眠时也能运行。官方概览：Codex Cloud

我也会先在 ChatGPT dot 里交代目标和已有 context，让 dot 把工作交给另一个 Codex Cloud Task，再协调进度和结果。我把这条路径称作 workflow handoff：dot 负责协调，Coding Task 使用选定 Environment 中的 repo、toolchain 和服务访问配置执行工作。

官方文档也确认，dot 可以在已配置的 Codex Cloud Environment 中创建 Coding Task，检查结果并发送 follow-up instructions。这些 Cloud Task 会出现在桌面、网页和手机端，我可以直接进入对应对话补充要求，也可以继续通过 dot 跟进。官方指南：Tasks and memory

这让我可以先讨论功能范围和验收要求，再把明确的工作交出去。结果回来后，在 dot 里调整优先级，或进入 Coding Task 看 diff、检查测试。需求讨论、执行和反馈有了衔接，我不必始终守着最初发起工作的那个入口。

flowchart TB
    U["User<br/>Goal and review"] <--> D["ChatGPT dot<br/>Coordinate and follow up"]
    D <-->|"Brief, context and results"| C["Codex Cloud Task<br/>Published Environment"]
    D <-->|"Brief, context and results"| L["Local Work / Codex Task<br/>Connected computer"]
    classDef coordinator fill:#eef3ec,stroke:#9cb695,color:#24332c;
    classDef execution fill:#f5f6f3,stroke:#bdc9b8,color:#24332c;
    class D coordinator;
    class C,L execution;

图中的箭头表示 workflow handoff：dot 把目标和 context 交给具体 Task，再接回执行结果、继续协调。

执行位置决定了运行条件：Cloud Coding Task 需要预先配置 Environment，个人电脑可以离线；dot 创建 Local Work / Codex Task，或继续已有 Local Codex Task，则需要已连接、已授权的电脑保持在线，并打开 ChatGPT app。dot 自带的 cloud computer 与项目的 Codex Cloud Environment 是不同的对象。官方指南：Connect computers and apps to your dot

新 Task 接收的是 dot 为这项工作提供的 instructions 和 context，不会自动继承全部对话历史。因此，handoff 仍要交代清楚目标、相关 repo、已有结论、验收命令和未解决的问题。切换入口能够省下多少重复解释，取决于这次交接是否完整。

2. Environment 是可复用准备，Task 是独立执行

要把这套流程用顺，先分清三个对象：

一个 Environment 可以关联多个 Repository。不同 Task 复用同一套准备结果，各自维护独立 workspace：项目的准备工作可以共享，具体工作的状态分别保存。

图中展示的是准备结果的复用与 Task workspace 的独立性。

同时做三个 Task，不必先复制三套相同的 Environment；项目使用 Python、Rust、Go 或 Node.js，也不必因此按语言拆分。

前端、后端和 SDK 如果经常需要一起阅读和修改，共用 Environment 很自然。互不相关、所需服务和 credential 也不同的项目，我更愿意拆开。Environment 的边界最好与协作需求和 authorization scope 一致。 跨 repo 的改动仍需分别审查和交付。

更新也遵循这个边界：调整 Environment 后，需要 Republish，后续新 Task 才会使用新的 prepared filesystem。已有 Task 保留自己的文件、未提交改动和安装工具。验证更新时，应从新 Task 开始。官方指南：状态复用与更新

官方文档 UI 示意：从 Environments 列表的 Edit 入口更新已有配置；图中项目为官方示例。来源

3. 配置 Environment：让 Agent 准备，再验证

导入 GitHub repo 后，Codex 会分析所需 runtime、dependencies、credential 和 egress domains，并协助判断、预填 Environment Variable 与 Network Secret。我需要审核这些建议，在配置界面填写自己掌握的 values，再验证结果。整个过程都可以继续对话。

当前的创建入口是网页或桌面端的 Work in → Cloud → Select environment → Create environment，也可以从 Settings → Codex Cloud → Environments 进入。选择 GitHub repo 后，Codex 会检查项目，安装 dependencies 和工具，并测试 workflow。手机端可以选择已发布 Environment 开始 Task；新 Environment 的创建放在网页或桌面端完成。官方指南：创建并发布 Environment

官方文档 UI 示意：选择已准备的 Environment，或通过 Create environment 创建新配置。来源

准备过程中，Agent 先读 repo、尝试安装，根据报错修正，再向我询问缺失信息。我可以直接补充“这里使用 uv”“遵循 repo 里的 Rust toolchain 声明”“Node 版本以项目配置为准”。这些要求会进入下一次配置和验证，不必由我先写成完整的安装脚本。

准备工作可以记录在两个字段中：Install script 保存安装 dependencies、准备开发资源的命令；Start skill 说明如何启动服务、检查 readiness。前者负责准备，后者负责让服务运行起来并确认状态。官方指南：安装与启动配置

网络配置中，开启 Allow Codex to access internet 后，可以选择 Package managers 预设或 Custom domains only，再补充 Additional allowed domains。预设已覆盖常见的 npm、PyPI、Rust 和 Go dependency 来源；其他 API host、下载 host 和 subdomain 仍要分别检查。官方指南：连接服务

我会用下面这样的请求交代准备要求。它是配置模板，具体结果仍需执行验证：

请根据所选 repo，为日常开发和测试准备 Codex Cloud Environment。

先阅读 AGENTS.md、README、dependency manifests、lockfile 和 toolchain 声明。
Python 使用 uv；Rust、Go、Node.js 版本遵循各 repo 已有配置。
安装必要 dependencies，分别验证 build、测试，以及需要启动的服务。

识别缺少的配置项，并为每项说明：
- 对应的代码或配置依据；
- 适合 Environment Variable 还是 Network Secret；
- 请求实际发往哪些 domain；
- 是否必须才能完成基础测试。

请预填可以推断的配置，real credential 由我在配置界面填写。
最后报告已通过的检查、尚未验证的步骤和失败原因。

验收时，我会要求分别报告工具安装、dependency 下载、离线测试和真实服务调用的结果。对 Agent 项目，mock 测试通过还不足以说明模型或工具的真实调用能够成功。

检查准备报告、配置和文件后，再保存并点击 Publish，将准备结果提供给后续 Task。这里发布的是 Environment；代码合并和应用部署仍有各自的交付流程。官方指南：创建并发布 Environment

这个流程省下的是我独自拼装配置的工作。Agent 提出版本、credential 和 domain 的需求，再通过执行结果说明哪些已经可用、哪些还缺条件。其中最让我好奇的，是项目怎样获得 API 访问能力，而不必直接拿到 raw credential。

4. 核心设计：Credential 如何交付给 Agent

最初看到 Secrets 和 Personal Vault，我也想知道：它们最后是不是都作为 Environment Variable 交给 Agent？

这里要分清两个维度：谁管理值，以及程序怎样得到它。

先看 delivery：程序读取 Environment Variable 时得到配置值；读取 Network Secret 对应的变量时，得到 placeholder。Proxy 会在发往允许的 HTTPS 目标的 request 中，将 placeholder 换成 raw credential。这两种 delivery 方式都可以与不同 ownership 组合：

Personal Vault 管理值的保存与适用范围；delivery 决定 raw value 是否交给程序。 因此，配置 UI 遮罩了 Value，并不意味着 Task process 读不到它。官方指南：Environment Variable、Network Secrets 与个人值

Environment Variable：程序直接读取

例如 APP_MODE=development，程序通过正常的 Environment Variable 接口读取即可。如果放进去的是 API key，Task process 得到的也是真实值，Agent 执行的脚本、dependencies 和调试代码都可能读到它。这种方式兼容面广，代价是 raw credential 进入了 Task execution environment。

Network Secret：Placeholder 与 Proxy-side Injection

以使用 Bearer Token 的 HTTPS 服务为例，配置可以写成这样。这里使用占位示例：

Type: Network secret
Key: SERVICE_API_KEY
Value: 在配置界面填写 real value
Allowed domains: api.example.com

官方文档 UI 示意：Manage secrets 将 Key、隐藏的 Value、Ownership 和 Allowed domains 放在一起。图中的 REGISTRY_TOKEN 与 packages.example.com 均为官方示例。来源

程序仍通过 SERVICE_API_KEY 读取配置，得到的却是 placeholder。它将 placeholder 放进 request；Proxy 检查目标符合规则后，替换为 raw credential，再转发给 server。

图中的 Configured binding 表示 Key、Value 和 Allowed domains 的配置关系。真正的信任边界在于：Task process 使用 placeholder，Proxy 负责向允许的目标交付 raw credential。

官方说明，这种 substitution 适用于 HTTPS :443，在 Environment 准备和 Task 执行阶段都可生效；raw credential 不会通过这种 delivery 进入 Task process 或文件。官方说明：Network Secret 的交付与约束

查资料时要留意版本：Legacy Environment 的 Secrets 仅在 setup 阶段可用，在 Agent 阶段开始前会被移除。它与当前 Network Secret 的机制不同。Legacy 文档：Secrets 的 lifecycle

我觉得这个设计漂亮，是因为它利用了 API 调用中的一个特点：业务代码通常只需把 Token 放到正确的 request 位置，无需理解 Token 的内容。于是，程序可以使用 API，却不必持有 raw credential。

Agent 经常查看 log、运行测试和调试命令，项目还可能包含不可信 dependencies。让 raw credential 留在 Task process 之外，能减少它被直接打印、写进文件或带入 context 的机会。

Placeholder 并不适用于所有 Credential 用法

对于把 Token 原样放进 HTTPS 请求的 client，proxy substitution 是很自然的方案。如果程序要在本地用 secret 计算 HMAC、给内容签名，或者读取 SSH private key 完成 authentication，placeholder 就无法直接替代 real value 参与计算。请求使用非 443 端口、走其他协议，或 SDK 没有正确使用 managed proxy，也不能从 Network Secret 的文档约束中推导出兼容性。

delivery 的选择取决于程序怎样使用 credential，变量名叫 API_KEY 并不足以决定方案。

能够替换 HTTPS request 中的 credential，也意味着 Proxy 是受信任的请求处理环节，需要接触相应的 HTTP 内容。至于 TLS 如何终止、连接如何建立，本文引用的产品文档没有给出完整实现。

Personal Vault：个人值按需求交付

Personal Vault 保存个人的 Environment Variable 和 Network Secrets，Applies to 决定它们适用于全部还是指定 Environment。只有 Environment 请求的值才会交付给 Task；同一个个人配置中，特定 Environment 的值优先于通用默认值。官方指南：个人值

操作入口是 Settings → Codex Cloud → Personal vault → Add：选择 Type，填写与 Environment 需求一致的 Key 和对应 Value，再选择 Applies to。Network Secret 的允许目标在 Environment 配置中审核；直接变量与 Network Secret 应使用不同的 Key，避免混淆交付方式。

官方文档 UI 示意：这里添加的是 Environment variable 类型的 APP_MODE，值为 development；Personal Vault 也可保存 Network Secret，填写时应先看清 Type。来源

共享 Environment 可以声明“需要某个 Key”，再由每个人提供自己的值。共享这份需求不会共享个人 credential。Environment 自带的 credential、VPN identity 和准备好的文件则另当别论，共享前仍需审核其中包含的访问能力。

5. 验证 Request Path 与 Authorization Boundary

配置好 Network Secret 以后，我会沿着一次服务调用检查三件事：

domain 可达、credential 交付成功、upstream 允许当前操作，需要分别成立。填好 Key 只解决了这条链路中的一部分。

保存 Environment-owned Network Secret 时，它的目标会加入受限网络配置；Environment Variable 和 personal values 不会自动添加目标。因此，使用 Personal Vault 后，还要检查 Environment 的 network policy。官方指南：credential 目标与 network policy

即使 Agent 已经预填，也要核对实际请求。dependency 下载可能重定向到另一个 host，API 的 base URL 也可能被项目改过。配置正确与否，最终要由实际 request path 说明。

先验证最小 Request，再验证实际 SDK

我会先用最小 HTTP request 检查 authentication path，再测试项目实际使用的 SDK。下面是一个结构示例，api.example.com 和 /health/authenticated 都是占位地址，必须替换为目标服务官方提供的低成本 authentication 检查接口，不能直接照抄当成可运行测试：

# 不启用 set -x，不使用 curl -v，不回显 credential 或完整 request header。
curl --silent --show-error --fail \
  --output /dev/null \
  --write-out 'HTTP %{http_code}\n' \
  --header "Authorization: Bearer ${SERVICE_API_KEY}" \
  https://api.example.com/health/authenticated

这条 request 用于检查目标是否可达、Proxy substitution 是否生效，以及 server 是否接受 authentication。结果仍需按目标 endpoint 的语义判断，不能把任意 HTTP 200 都当作 authentication 成功。

如果最小请求成功，而 SDK 失败，再检查 SDK 的 proxy support、base URL、TLS trust 配置，以及 credential 是否经过本地编码或签名处理。curl 成功只证明这条 request path 成功，不能代替 SDK 验证。保留平台配置的 Proxy 和 CA trust；关闭 certificate verification 不会验证 Credential Injection 是否正确。

如果最终改用 Environment Variable 直接传入 raw credential，就要接受它进入 Task process 的变化。这是一次 trust boundary 的调整。

排障时，我会让 Agent 报告目标主机、状态码、失败步骤和脱敏错误，而不要求它打印 Environment Variable 或完整 authentication header。遇到 401，先确认请求来源和 authentication 链路；遇到 403，也要区分 proxy policy 拒绝与 upstream service 拒绝，不能只凭一个状态码判定根因。官方指南：下载或 HTTPS 请求失败

准备阶段验证通过后，Publish / Republish Environment，再从新 Task检查一次实际 SDK 调用。

看不到 Key，仍然能够使用 authorization

Agent 拿到 placeholder 后，仍然可以调用获准的 API、消耗额度、读取数据，或执行 credential 允许的写操作。Network Secret 减少 raw credential 暴露，不会自动收窄它的 permission。

从这个模型看，allowed destination 本身也属于信任范围：如果目标服务把收到的 authentication 信息回显到 response 中，raw value 仍可能返回 Task。这是对机制边界的分析。

因此，我仍会使用独立 development credential，收窄 permission、设置用量限制；共享 Environment 时，检查是否附带了不必要的服务访问能力。

6. 底层如何组织，为什么用 VM？

学习时我也追问过：它到底是 Sandbox，还是 VM？这个问题需要先分清概念层次。

Sandbox 描述受约束的 execution environment 和 isolation boundary，VM 是实现隔离的一种技术。Container 和 VM 都可以运行 cargo build、go test；能否执行这些命令，取决于 toolchain、permission、资源和网络设置。

当前 Codex Cloud 文档确认，每个 Cloud Task 运行在 VM 中，新 Task 使用 published Environment 的 prepared filesystem，已有 Task 保留自己的 working state。官方指南：VM 规格

Environment 准备与 Task execution 分开看

图中串起了三层职责：Environment 定义项目需要什么；Publish 保存 prepared filesystem；Task VM 从这份准备结果开始执行，维护自己的 workspace 和 working state。官方指南：发布与状态复用

access configuration 单独画在右侧，因为文件复用与服务访问走的是不同路径。Network Secret 的 raw Value 由 Proxy 向允许的目标交付，不会先写进 prepared filesystem 再随 Task 复制。Task VM 内画出的是 workspace 和 Shell / build / test，model inference 与完整 Harness 的部署位置不在图中推定。

Prepared filesystem 也不能直接等同于包含 RAM 和运行中 process 的完整 VM snapshot。 官方披露了准备与恢复行为，尚不足以确定 snapshot 的内部格式与分发实现。

为什么 VM 适合这种工作？

下面按 workload 分析这项选择的合理性，不代表 OpenAI 已公开的内部选型理由。

Isolation boundary。 Coding Agent 会运行生成的 Shell、repo 脚本、第三方 dependencies 及其触发的子 process。一条普通的安装或测试命令，也可能执行项目提供的任意代码。相比共享 host kernel 的普通 Container，VM 通常通过独立 guest kernel 和 hypervisor 增加一道隔离边界。OpenAI 的通用 Sandbox security 指南也建议用 VM 等 isolated compute 承载 workload；它支持这项隔离原则，但没有说明 Codex Cloud 的具体选型过程。官方指南：Isolate workloads

Task resources 与 lifecycle。 编译、测试和启动服务会消耗 CPU、RAM 与 Disk，还可能遗留后台 process 或修改系统配置。Task VM 为资源分配、启动、保存和回收提供了独立管理单元。Container 也能用 cgroups 等机制控制资源；VM 的取舍在于，将这些 lifecycle 操作与前面的隔离边界结合。

准备与复用。 提前准备 filesystem，再交给独立 Task，可以减少重复初始化。VM 可以与这套准备、恢复和回收模式配合；其他方案也能复用 filesystem，这项能力本身并非 VM 独有。

代价同样存在：guest OS、虚拟化设施、启动和状态管理都需要资源与运维投入。是否采用 MicroVM、怎样预热、恢复需要多久，要看实际方案和测量。VM 也不能包办 network policy、Credential Injection 与 authorization，这些仍需独立控制。

哪些实现细节仍然未知？

具体使用哪种 hypervisor、是否采用 Firecracker、VM 内是否还有 Container、snapshot 如何分发，以及 credential storage 与 Proxy 如何通信，仍不能从产品行为中反推。开源 Codex 中存在相关代码，也不足以证明云端生产服务部署了同一实现。

早期或 Legacy 文档里的 Container 描述，应结合产品版本、执行路径和系统层次理解。分析可以依据公开的行为继续深入，具体 deployment topology 则需要额外证据。

7. 我的实际边界：公司接入、能力与 Usage

目前对我最大的限制，是公司代码和开发服务位于内网。把个人 GitHub repo 导入云端相当顺畅，但云端 Task 不会自动继承办公电脑的 VPN、内部 DNS、SSO session 和公司工具 permission。

不过，把这个现状概括为“Codex Cloud 不能访问任何内网”也不准确。截至本文核对日期，官方已经支持 Tailscale private networking，可以通过相应设置接入内部 HTTP/HTTPS 服务，并支持 private IPv4 subnet routes、split DNS 和 MagicDNS。目标还需要同时满足 VPN 规则和 Environment network policy。官方指南：Private networking

要把这条路径用在公司，还需要确认网络接入、代码使用、identity 和审计的 authorization。现有 VPN 与 SSO 也不会自动兼容 Tailscale。我目前顺畅迁移的是个人项目、学习实验和可独立验证的 Task；公司内网开发仍未跑通。

另一个区别是“访问内部服务”与“原生导入内部 Repository”。当前指南仍把 GitLab、自托管 GitHub Enterprise Server，以及 computer/browser use列为尚未支持的能力。本机个人 skills 也不会自动同步到云端，放在 repo 里的 skills 才随项目可用。官方指南：当前限制

因此，命令行 build、Unit Test、浏览器 UI 验证，以及公司真实开发 Environment 中的验证，仍是不同的验收步骤。Cloud Task 跑通了其中一部分，就只报告这一部分。

Connection、资源与 Usage 各有边界

Environment Variable 与 Network Secret 描述配置值的 delivery。GitHub connection、VPN connection 和 OIDC 则各有接入流程。当前 OIDC 可以为 Task 获取 short-lived cloud credential，但仍是按申请开放的 Enterprise 能力，也不会自动继承个人账号的全部 permission。官方指南：OIDC

学习时，我还两次问过“能建几个 Environment”。后来发现，需要先把三个问题分开：

官方 VM resources 与 Pricing 分别说明资源和 usage。项目中的程序再用独立 provider API key 调模型或工具，还需要考虑对应 API usage；不能把它与 Coding Agent 自身的 subscription usage 混为一谈。

Task state 也有期限。官方当前默认可在最后一次开启轮次或恢复 Task 后的七天内恢复保存的 VM state。重要改动仍需进入 Git，必要的输出也要保存。资源、usage 与恢复期限会变化，使用时应查当前文档。

8. 从这次体验里，我想借鉴什么

这次体验里，Environment provisioning、Credential delivery 和 dot 的协调各自解决了一个实际问题：项目怎样准备好，服务访问怎样交付，工作又怎样在不同入口之间继续。三者接在一起，才有了从手机交代工作、离开电脑后仍能推进的使用体验。

如果借鉴到自己的 Agent 系统，我会先分清 Harness 与 Sandbox 的职责：Harness 组织目标、context、Tool loop 和 handoff；执行基础设施约束 workspace、process、network 与 lifecycle。再依据 workload 选择 Container、MicroVM 或 managed Sandbox，可信的内部 Worker 与运行未知 Repository 的环境，可以有不同要求。

落地时先验证一条小链路：从 repo 识别 Environment requirement，让人审核 credential 与 egress scope，再用真实 request 检查访问结果。能把配置依据、执行过程和失败原因说明白，再逐步补充恢复与调度能力。

我仍然需要审查代码，确认哪些测试真实跑过，处理公司内网和 production release 的边界。至少在个人项目里，我已经可以把一项明确的工作交出去，等合适的时候，再从手机上回来接着做。