代码要交给远程智能体执行，却不确定工作区、密钥和网络权限会不会一起暴露？
最快的判断是：OpenAI Codex 自托管沙箱部署只把 executor 执行环境放到自己的机器上，模型与 agent harness 仍由 OpenAI 运行。按用户或工作负载隔离环境，为 executor 配置受限的独立环境密钥，并把应用 API 密钥留在沙箱之外。若需求只是让 Codex CLI 在远程主机上运行，那是另一种用法。
计划把代码执行环境迁到远程服务器的 AI 应用开发者与小型研发团队，可用本文核对环境组成和连接方式。
需要智能体访问内部代码或工具的团队，可据此规划隔离边界与凭据权限。
正在比较本机、容器与远程执行环境的技术负责人，可用部署和验收步骤评估维护成本。
最后更新于 2026 年 11 月 2 日；架构、连接目标、密钥权限及生命周期信息已对照 OpenAI 官方文档核实。NodeKVM 配置以当日可查的产品页为准。
部署前分清执行器与远程 CLI
Agents API 自托管方案不是把模型推理服务安装到服务器。官方架构是 OpenAI 运行 agent harness，用户环境运行 codex exec-server；执行器按 harness 的请求运行命令、读写工作区，并可使用环境内的本地 MCP 服务。自托管的是计算与文件环境，不是模型本身。关于职责边界，可对照官方架构说明和自托管沙箱连接流程。
Agents API 自托管沙箱与远程主机运行 Codex CLI 的区别
前者由应用创建 session，再把返回的环境 ID 和连接地址交给 executor；后者是在远程主机上直接运行 CLI，不能据此推断已经接入 Agents API 自托管环境。若团队需要 API 驱动的智能体执行流程，应按自托管沙箱流程设置；若只是开发者通过 SSH 登录后操作代码，则要单独评估 CLI 的账户认证和执行权限。
| 方案 | 谁负责调度 | 代码在哪里执行 | 适合的需求 |
|---|---|---|---|
| Agents API 自托管沙箱 | OpenAI agent harness | 用户控制的 executor 环境 | 应用通过 API 创建会话，需要自控工作区或接入自己的计算环境 |
| 远程主机运行 Codex CLI | CLI 所在主机上的交互流程 | CLI 可访问的远程主机目录 | 开发者通过 SSH 登录后直接操作代码 |
| OpenAI 托管沙箱 | OpenAI | OpenAI 提供的沙箱 | 不需要自定义执行环境，希望减少环境维护 |
选择容器还是远程服务器，不应只看“哪种更安全”。关键是每个任务能否获得独立文件系统、凭据和网络权限。官方文档提醒，共享执行环境的智能体可能访问同一批文件、凭据和其他资源；容器若共用宿主目录或凭据，也不能只凭“容器化”就认定隔离充分。
先确定环境边界，再准备运行条件
先把工作区按用户或工作负载划分，再决定代码、依赖和本地 MCP 服务是否进入执行环境。不要默认所有仓库都能由同一个 executor 访问。若多个团队共用机器，至少区分工作目录、运行账户、凭据注入方式和可访问的内部服务；无法隔离的资源，就不要交给智能体执行。
容器、本机与远程服务器的选择依据
官方支持的环境形态包括笔记本、容器和远程沙箱。个人试验可从本机开始；依赖固定、需要快速重建环境时，可评估容器；需要长期运行、集中管理仓库或接入内部工具时，再评估远程主机。最终判断标准不是机器规格，而是能否落实隔离、权限和回收责任。
| 执行环境 | 适用情况 | 上线前要确认 |
|---|---|---|
| 本机 | 个人试验，代码和依赖都在开发者设备上 | 本机账户权限、工作目录、终端退出后的进程状态 |
| 容器 | 需要固定依赖、快速重建环境或隔开部分宿主资源 | executor 所需能力、宿主挂载、特权模式和密钥注入范围 |
| 远程服务器 | 需要持续在线、集中管理依赖或运行长期任务 | 工作负载隔离、SSH 管理权限、出站网络限制、日志与环境回收 |
按以下顺序准备环境，避免把临时测试步骤未经核验地变成生产配置：
- 选定运行位置与隔离单位。先决定按用户、仓库还是任务分配执行环境，并明确谁创建、维护和回收环境。
- 准备工作目录和依赖。官方示例使用
/workspace；应用创建 session 时指定的工作目录，必须与 executor 实际使用的目录一致。 - 安装 Codex CLI，并在发布时复核官方当前安装说明及
codex exec-server的适用版本。不要把未固定版本的示例安装命令直接复制到生产镜像。 - 为应用端和 executor 分别准备凭据。应用 API 密钥留在控制器或应用服务内；executor 使用单独的环境密钥。
- 先验证必要的出站访问，再启动 executor。测试通过前，不要接入含生产秘密的仓库。
Agents API 的配置文档说明，创建 session 时要选择执行环境类型；对于自托管环境，应用需准备自己的计算资源并连接 executor。部署前还要决定 session 和工作区的生命周期由哪个组件管理。
收紧出站网络与密钥权限
执行环境的出站连接范围
官方自托管文档列出两个连接目标：通过 https://api.openai.com 注册环境，以及通过 wss://codex-cloud-environments.chatgpt.com 收发命令和结果。连接由 executor 主动发起。按此连接流程，重点是允许所需的出站访问，不要自行假设还要开放面向公网的 executor 入站端口。启用了域名白名单时，还要验证 DNS、代理和 WebSocket 连接。
密钥要按用途分层，不要为了方便把同一个全权限密钥注入所有容器：
| 凭据 | 放在哪里 | 权限与风险处理 |
|---|---|---|
| 应用 API 密钥 | 应用控制器或密钥管理服务 | 用于应用所需的 API 请求；不要放进工作区、镜像或构建日志 |
| executor 环境密钥 | 启动 executor 时注入其运行环境 | 用于环境连接；只保留所需权限 |
| 第三方工具凭据 | 可信代理或处理工具调用的应用端 | 通过代理或应用侧工具按需转交，不直接暴露长期凭据 |
环境密钥供 executor 连接环境使用，应用 API 密钥由应用发起 API 请求。官方建议环境密钥仅保留环境连接权限，并将应用密钥放在沙箱外。需要注意，智能体生成的代码可能读取 executor 环境里的变量；因此环境密钥虽然受限，仍不能写入仓库、容器镜像或日志。怀疑泄露时，应撤销或轮换密钥。更完整的密钥边界见官方沙箱安全说明。
若代码确实需要访问第三方服务，优先把凭据留在可信代理或应用侧，由代理按目标地址和权限范围转发。把密钥注入执行环境，不等于它对智能体不可见。OpenAI 的Codex 安全实践文章介绍了将沙箱、审批策略、网络限制与审计记录结合起来的做法；人工审批不能代替文件系统和网络隔离。
启动后按连接状态验收
创建 session 后，应用应保存状态，并将返回的环境 ID 和远程连接地址传给执行环境。官方启动示例使用 codex exec-server，并提供 --remote 与 --environment-id 参数。下列命令只说明参数关系；占位符需要替换成当前 session 返回的值，环境变量应通过安全的运行时方式注入，而不是写进代码仓库。
codex exec-server \
--remote "<session.environment.remote_url>" \
--environment-id "<session.environment.id>"
在应用端监听 session 事件。收到 agent.session.environment.connected 后，再提交不含敏感信息的测试任务。若状态停留在 pending，核对 executor 进程、环境 ID、连接地址、密钥归属和出站规则；若状态为 failed，查看环境错误与 executor 日志。连接成功只证明通信路径可用，不代表代码执行风险已经消除。
上线验收按单执行：
- [ ] 测试仓库不含生产密钥、真实客户数据或未公开的敏感文件。
- [ ] executor 只能读写预定工作区，不能遍历无关用户目录。
- [ ] 应用密钥未出现在执行环境、容器镜像、源码和日志中。
- [ ] 环境密钥权限受限，已验证撤销或轮换流程。
- [ ] 只放行必要的出站目标；确认 WebSocket 可连接，且没有无故开放公网入站端口。
- [ ] 测试普通读写、依赖安装策略、MCP 调用边界与网络限制。
- [ ] 测试断线后的状态处理；确认应用不会在原任务仍等待连接时重复提交。
- [ ] 为失败任务、异常命令和环境回收保留可审计记录。
断线重连也要写进应用逻辑。官方生命周期文档说明，连接中断可能导致工具调用失败，且等待环境连接最长为 5 分钟；不能只凭 session 显示空闲就关闭计算环境。超时后先检查原请求或 session 的结果，再决定是否重试，避免同一任务重复执行。应用还需为每个 session 管理对应计算资源，并明确环境关闭和工作区文件保留策略。具体启动、重连与清理边界可查阅官方沙箱生命周期说明。
长期运行前核算资源和维护责任
远程环境是否适合长期运行，不能只按 CPU 核心数估算。仓库体积、依赖构建频率、并行任务数量、缓存策略、日志留存和内部网络需求，都会改变资源需求。没有适用于所有项目的最低配置；先用代表性仓库验证峰值磁盘占用和构建时资源，再确定容量与并行度。
若需求是长期在线、整机独享的 Linux 执行环境，可以核对 NodeKVM 当前公开规格。下表信息来自NodeKVM 价格页，不能据此推算 Codex 性能或官方兼容性；价格及选配成本应以页面当时显示为准。
| 配置项 | 128GB 档 | 256GB 档 | 对执行环境规划的意义 |
|---|---|---|---|
| CPU | AMD EPYC 7543P，32 核 / 64 线程 | AMD EPYC 7543P，32 核 / 64 线程 | 可用于评估构建与多服务并行；规格不能直接代表 Codex 任务速度 |
| 内存 | DDR4-3200 ECC RDIMM，128GB | DDR4-3200 ECC RDIMM，256GB | 按实际构建峰值、缓存和同机服务选择 |
| 默认存储 | 2 × 1TB NVMe 直连 | 2 × 1TB NVMe 直连 | 两盘合计可用容量为 2TB，不是 RAID-1 镜像；冗余与机外备份需另行规划 |
| 默认网络与位置 | 250 Mbps，不限流量；日本东京 | 250 Mbps，不限流量；日本东京 | 核对镜像拉取、代码仓库访问和团队管理链路是否合适 |
| 月付基础价 | $465 | $592 | 页面所列月付基础价；选配与其他计费周期需另行核对 |
节点长期运行期间，还要把维护责任落到人和流程上：更新系统与依赖、轮换环境密钥、复查 MCP 与出站规则、清理旧工作区，并确认日志不会记录秘密。如果应用按 session 动态创建环境，还需实现重复请求去重和失败回收。销毁并重建计算实例时，复用环境 ID 并不会自动恢复文件；若需保留工作区，应另行设计持久化存储。自托管环境的文件也需要由自己的基础设施取回和保存，相关边界见官方文件与产物说明。
如果只是短时试验、低负载或偶尔手动运行，开发者本机或临时容器通常更省维护成本。如果需要团队共用、持续在线或控制代码所在的整机环境，独享服务器才更值得评估。共享云主机可能受到同机负载影响，也可能限制系统和资源控制；独享机器则要求团队自行承担系统更新、权限配置和备份责任。NodeKVM 的可用配置与服务说明可在产品信息页核对；接入方式和使用说明见帮助页面。有长期运行 executor 的实际需求时，再结合仓库负载、隔离设计和维护能力判断是否适合租用 NodeKVM。