AutoGPT 平台 Codex 订阅直连（Subscription Transport）私有预览指南：打通 ChatGPT 账号与 Codex App Server 的三种执行路径-平芜编程栈

AutoGPT 平台 Codex 订阅直连（Subscription Transport）私有预览指南：打通 ChatGPT 账号与 Codex App Server 的三种执行路径

【免费下载链接】AutoGPTAutoGPT is the vision of accessible AI for everyone, to use and to build on. Our mission is to provide the tools, so that you can focus on what matters.项目地址: https://gitcode.com/GitHub_Trending/au/AutoGPT

AutoGPT 平台（autogpt_platform）提供了一项连接自有 ChatGPT/Codex 订阅账号的能力，把账号自己的 Codex 额度接入现有的 Code Generation 块、AutoPilot 会话与 AutoPilot 图节点执行。本文以 docs/platform/codex-subscription-preview.md 为主体，结合 blocks/codex.py、codex_preview_smoke.py、docker-compose.platform.yml 等仓库源码，说明该私有预览的范围、本地运行与验证步骤、部署成私有云预览的注意事项，以及设计上的安全边界，帮助你在自己的 AutoGPT 部署中完成"用 ChatGPT 订阅额度跑 Codex"这条链路的搭建与排查。

预览范围：什么流量走 ChatGPT 订阅，什么不走

该功能本质是一个订阅传输层（subscription transport）：codex作为凭据提供方（credential provider），Codex App Server作为执行运行时（execution runtime）。用户连接一个 ChatGPT 账号后，该账号的 Codex 额度被用于以下三条显式的执行路径：

既有的Code Generation块，通过codex_app_servertransport 执行；
新建的AutoPilot聊天会话——当ChatGPT/Codex是唯一已连接的订阅传输时自动选用，或当连接了多个订阅传输时由用户显式选择；
AutoPilot 图节点，在节点上显式选择一个 ChatGPT/Codex 连接后执行。

需要特别强调的是边界：ChatGPT 套餐并不是无限推理。这些调用会消耗所连接账号的 Codex 额度（allowance）或 credits，并受其速率限制约束。订阅支撑的用量会被记录为billing_mode=user_subscription（在 blocks/codex.py 的_record_subscription_usage中可以看到该字段与auth_provider="codex"、execution_path="codex_app_server"一同被写入执行统计），而不会被报告为 AutoGPT provider 的 USD 花费。

预览不会把下列流量路由到所连接的账号：Orchestrator、共享 LLM 块、图像生成以及后台系统任务。既有的图与 AutoPilot 会话保持各自存储的路由不变；只有当恰好连接了一个订阅传输时，新建的 AutoPilot 会话才会自动使用它。

本地运行与连接 ChatGPT 账号

从 autogpt_platform 目录启动整套栈：

docker compose up -d --build

与很多需要功能开关（feature flag）的私有预览不同，Codex 配对及其支持的执行路由不需要任何环境变量形式的 feature flag。Compose 栈为 REST、executor 与 Copilot executor 进程挂载了/run/autogpt-codex，一个内存支撑的临时文件系统（tmpfs）。在 docker-compose.platform.yml 中可以看到其定义：

x-codex-tmpfs: &codex-tmpfs - /run/autogpt-codex:rw,nosuid,nodev,noexec,mode=0700,size=128m

三个后端服务通过环境变量CODEX_TEMP_ROOT: /run/autogpt-codex指向它。这一 tmpfs 挂载对应 settings.py 中codex_temp_root字段的描述："Optional tmpfs root for isolated Codex runtime homes"——Codex 运行时所需的临时授权 home 目录必须落在内存盘上，不可放到持久化卷。

启动后，打开http://localhost:3000，进入Settings > Integrations并连接Codex。在弹出的登录窗口中打开 ChatGPT 的验证页面，输入一次性验证码（device code）完成配对。

Codex 登录背后的实现结构

从源码看，设备码登录并不是一段临时脚本，而是一个完整的状态机：

协调器 login.py 的CodexLoginCoordinator负责启动设备码登录、超时控制（默认codex_login_timeout_seconds=900秒）、取消与凭据持久化；
状态存储在 Redis 中，RedisCodexLoginStateStore以"每个用户只能有一个 active 登录尝试"的互斥逻辑运行，并维护 owner lease（默认 30 秒），防止多个 REST 副本同时接管同一用户的登录（login.py）；
登录完成后，OAuth2 凭据经upsert_single_provider_locked写入凭据库，凭据以provider="codex"、refresh_strategy="provider_runtime"标记（login.py），即刷新令牌由 Codex 运行时自身管理，而非平台常规 OAuth 流程。

登录状态接口位于 api/features/integrations/codex.py，包括POST /device-login/{login_id}/cancel等；其中的build_device_login_url（同文件 L139-L156）由FRONTEND_BASE_URL显式拼接登录页地址——这是后文部署配置的关键原因。

测试路径一：Code Generation 块（Codex App Server transport）

文档给出的操作步骤：

在图中添加Code Generation块；
将Transport设为Codex App Server；
选择已连接的ChatGPT for Codex凭据；
运行该图。

在块实现 blocks/codex.py 中，CodexExecutionTransport枚举只有两个值：openai_api与codex_app_server。凭据输入是一个带判别器的联合：CodexCredentialsField()（L112-L124）把 transport 值映射到不同 provider 与凭据类型——openai_api→ OpenAI API key；codex_app_server→oauth2类型的 ChatGPT 连接。运行时分流在块的run中完成（L301-L316）：API transport 走_run_openai_api（OpenAI Responses API），App Server transport 走_run_codex_app_server（经 credential lease 调用订阅运行时）。

需要注意的差异点：

既有图默认仍走 OpenAI API transport，需要显式切换；
块上的model 下拉框只作用于 OpenAI API transport。对 App Server 订阅路径，模型由"当前账号兼容的默认模型"决定——App Server 的实时模型目录（live catalog）可以独立于公开 API 的模型名变化，这一点在设计上就是有意为之；
reasoning_effort、max_output_tokens等高级参数同样仅对 API 传输有意义；App Server 路径直接把 effort 映射到 Codex 运行时的取值（blocks/codex.py），max_output_tokens则"由 App Server 使用其模型与套餐限额"。

代码中可看到的候选模型集合包括gpt-5.6-sol、gpt-5.6-terra、gpt-5.6-luna、gpt-5.3-codex、gpt-5.1-codex（blocks/codex.py），但这属于平台侧暴露的名称集合，实际可用性仍以所连账号在 App Server 上可见的模型为准。

测试路径二：AutoPilot 会话直连订阅

AutoPilot 上的操作流程：

打开AutoPilot并开始一个新任务；
如果 ChatGPT/Codex 是唯一已连接的订阅传输，则会话自动使用它且不显示连接选择器；若连接了多个订阅传输，则在发送第一条消息前选择所需的连接；
照常选择Fast或Thinking、Balanced或Advanced，然后发送消息。文本与获准的 AutoGPT 工具调用会经由既有的 AutoPilot 事件面流式返回。

文档强调的会话语义是：

路由与凭据被存到新会话上，且对该会话不可变。要换用另一个已连接订阅传输，请另开一个任务；
服务端在每个排队轮次（queued turn）之前重新加载权威会话路由；排队消息只携带credential ID，绝不携带 OAuth token；
凭据缺失、被吊销或忙时，都会显式失败——不存在静默回退到 AutoGPT 出资模型或他人凭据的情况。

模式/模型映射与执行池模型

"模式 + 模型"控件会先从共享模型目录（shared model catalog）选出一条 Codex 路由，再对照所连接账号公示的模型做校验。当账号暴露相应模型时，预览的映射关系为：

用户选择	映射模型
Fast / Balanced	GPT-5.6 Luna
Fast / Advanced 与 Thinking / Balanced	GPT-5.6 Terra
Thinking / Advanced	GPT-5.6 Sol

若账号没有暴露这些模型，则回落到该账号可见的默认模型。文件附件、构建 Agent 的工具以及 SDK 子会话，都走与平台出资 AutoPilot 相同的Claude Agent SDK路径。Builder 面板绑定的会话在本预览中保持平台出资——因为其持久会话在创建时没有 AI 连接选择器。

从执行层看，Copilot executor为每个已连接账号持有一个排他凭据租约和一个Codex 运行时，再把重叠的多个聊天多路复用到独立的 Codex 线程上。取消或结束其中某个聊天，不会停止它的兄弟会话。这一池是进程本地的：被路由到另一个 executor 进程或副本的请求目前无法加入该 owner 池，会以可重试的有界错误codex_credential_busy失败。因此文档明确指出：多副本的生产化部署需要凭据 owner 路由（credential-owner routing）或专用桥接服务。常规平台 AutoPilot 路由不受影响。

测试路径三：AutoPilot 图节点（块）

在图中添加AutoPilot块；
在ChatGPT / Codex connection下选择已保存的连接；
运行该图。

该图节点的凭据字段是引用型凭据输入（reference-only credential input），与路径一中的 Code Generation 块不同：

图校验只检查所有权；
导出（export）时会剥去凭据 ID；
图执行器（graph executor）不持有外层凭据租约；
只有在 Copilot executor 消费该排队轮次时，才会获取那个唯一的运行时租约。

这种设计在文档中被解释为：既保持正常的凭据重绑定（credential rebinding），又不会让嵌套执行路径死锁。把该字段留空则保持既有的平台出资行为。

底层传输：Claude Agent SDK harness + 回环 Messages 端点

AutoPilot 保留既有的Claude Agent SDK 与 Claude Code CLI作为其 agent harness。实现上，一个请求作用域（request-scoped）的回环 Anthropic Messages 端点把模型轮次翻译成固定的 Codex App Server 实验性dynamicTools协议；Claude Code 依旧拥有 MCP 工具循环、权限钩子、builder 行为、transcript、resume、compaction 与子会话机制，Codex 只负责用所选用户的 ChatGPT/Codex 凭据提供模型响应。

安全细节：

回环端点绑定在127.0.0.1的一个临时端口上，只接受为该轮次生成的随机 capability；
capability 被放进 Claude CLI 子进程环境；ChatGPT 的 access、refresh 与 ID token 从不进入该环境；
Anthropic 文本与 tool-use 事件复用普通 AutoPilot 使用的 Claude SDK 响应适配器。

配套的兼容网关实现位于 backend/copilot/sdk/（codex_compat_gateway.py及其测试codex_compat_gateway_test.py、codex_compat_cli_test.py）。

App Server 进程本身是 fail-closed 的：原生 shell、文件系统、web 搜索、apps、插件、环境、workspace 根目录以及审批请求全部被禁用，其沙箱为只读。任何副作用只能经由"Claude Code 已被允许通过 AutoGPT 的 MCP 与安全钩子调用"的工具产生。对应地，在 runtime.py 中可以看到_install_fail_closed_approval_handler这样的安装逻辑。

版本钉死是硬性要求

实现把openai-codex与其捆绑的运行时一起钉在0.144.4（runtime.py 中OPENAI_CODEX_VERSION = CODEX_RUNTIME_VERSION = "0.144.4"），并且不要单独浮动这两个依赖中的任何一个——runtime.py 中甚至有断言"Codex SDK and runtime must both be pinned to version 0.144.4"。

Claude Agent SDK 与其捆绑 CLI 同样由后端锁文件（backend lock）钉住。由于dynamicTools与兼容面对版本敏感，任何更新都必须在聚焦的协议测试、Messages 一致性测试与捆绑 CLI 测试全部通过后才能发布。这些测试在仓库中散见于 backend/integrations/codex/（如runtime_test.py、transport_test.py、launcher_test.py）与 backend/copilot/sdk/ 下。

验证既有本地 Codex 登录：smoke test

在启动整套栈之前，可先从 autogpt_platform/backend 运行内置冒烟测试，验证本地既有的 Codex 登录是否可用：

poetry run python -m scripts.codex_preview_smoke

脚本 scripts/codex_preview_smoke.py 会执行下列检查：

复制而非移动~/.codex/auth.json到一个隔离的临时 home（注意源码中TemporaryCodexHome.create(temp_root)与materialize_auth_bundle的组合）；
校验账号、模型与速率限制（runtime.account()、runtime.models()、runtime.rate_limits()）；
执行一次订阅支撑的推理轮次；
检查运行时无法读到 host canary（host-canary.txt与环境变量AUTOGPT_CODEX_SMOKE_CANARY），也没有改写源登录文件——源码会在结束前对源文件与临时 home 中的 auth bundle 做 SHA-256 摘要比对（codex_preview_smoke.py）。

冒烟测试结束时会输出 JSON，包含 runtime 版本、账号类型（account_type）、套餐类型（plan_type）、速率限制套餐、可见模型列表、最终回复与 token 用量。注意：它会真实消耗所连接账号的一小部分 Codex 用量。

部署私有云预览

Codex 配对与其支持的执行路由不需要 availability flag 或前端构建期覆盖。文档建议：用部署自身的普通访问控制来圈定私有预览范围，而不要试图用环境变量隐藏设备登录。

部署前的架构要求：

REST、executor、Copilot executor必须共享普通 AutoGPT 的凭据数据库、加密配置与 Redis 集群；
每个可能启动 App Server 的进程都应有一个隔离的内存支撑CODEX_TEMP_ROOT，绝不能挂载在持久卷上（本地 Compose 中/run/autogpt-codextmpfs 的mode=0700,size=128m即对应此要求）。

三个 URL 环境变量

环境变量	语义	作用对象
`FRONTEND_BASE_URL`	预览的精确公开源（含`https://`scheme、不含路径）	REST（运行时）
`NEXT_PUBLIC_FRONTEND_BASE_URL`	同上，但会被编译进前端 bundle	前端镜像 build arg
`BETTER_AUTH_URL`	预览的精确公开源	前端（运行时）

FRONTEND_BASE_URL会被 REST 用来从配置的 origin 构建设备登录 URL，而不是信任转发的 Host 头（见 api/features/integrations/codex.py 的build_device_login_url）。如果云预览里遗留了 production 或 localhost origin，弹窗会被送到一个没有该预览 Better Auth cookie的 host 上。本地开发 Compose 文件把三者默认转发为http://localhost:3000（docker-compose.platform.yml）。

登录状态与副本限制

设备登录状态与所有权由 Redis 支撑，因此轮询与取消可以命中不同的 REST 副本；
但活跃的 App Server 登录 actor 仍是进程本地的：owner pod 重启会中断登录，其它副本无法接管或恢复它。因此滚动部署应避开活跃登录期；用户侧只需重新发起一次登录即可。要做广域云 rollout，必须把登录 actor 迁移到下述专用桥接服务中。

网络要求

容器需要出站 HTTPS 访问 OpenAI 的 ChatGPT/Codex 端点；由于 Codex App Server 采用轮询设备码完成状态的方式，不需要 OpenAI 的回调入站（callback ingress）。

预览安全边界与部署限制

文档列出的安全边界可概括为：

加密的、USER 作用域的IntegrationCredential行始终是凭据的事实来源（source of truth）；
原始 ChatGPT token 不会进入Redis、RabbitMQ、前端响应、容器级环境变量或 AutoPilot 会话记录；
每次原生调用或共享 AutoPilot 运行时 actor 都会把授权材料实体化到隔离的临时 home。AutoPilot actor 只在仍有重叠聊天挂接期间持有该 home，在整个生命周期与关闭时都会 checkpoint Codex 管理的刷新凭据，然后清理 home（可在 temporary_home.py 与 auth_bundle.py 中看到对应实现）；
Code Generation 轮次不暴露动态工具或 host workspace；AutoPilot 只暴露其既有 Claude SDK/MCP harness 注册的工具；
运行时复用严格限定在同一用户同一凭据；凭据绝不跨用户池化，也不被替换成另一账号；
不存在静默的平台 key 回退。

当前形态不等于生产安全边界

文档给出的结论非常明确：当前实现是在普通的 REST、executor 与 Copilot executor 容器内进程内（in-process）启动 Codex App Server的。这些容器以 root 运行，并且保留了后端服务更宽泛的数据库、Redis、文件系统与网络权限。临时 home 与 fail-closed 线程配置降低了暴露面，但并不构成面向广泛外部云部署的安全边界。

因此：

当前形态只适合本地开发或严格控制访问的员工/私有预览；
在对外部用户开放前，必须把运行时与设备登录监管迁移到专用的非特权桥接服务中，要求包括：非 root 用户、只读 root 文件系统、去掉多余 capabilities、纯内存凭据 home、进程与并发限制、收窄的出站流量，以及最小权限的内部凭据租约接口；桥接服务还必须拥有登录 actor 接管或显式重启语义；
在更广的 rollout 前，还需完成针对 hosted subscription passthrough 的商业与政策审查。

小结：一句话掌握该预览的取舍

这个私有预览的价值在于：让你（或你的用户）在 AutoGPT 平台上把自有 ChatGPT 订阅变成 Codex 执行引擎，覆盖 Code Generation 块、AutoPilot 聊天与 AutoPilot 图节点三条路径，同时在凭据隔离、模型目录独立演化、fail-closed 沙箱等方面做了严格约束。它的代价与局限同样清晰：消费的是用户订阅额度、受限于账号速率、执行池进程本地化（多副本需要 owner 路由或专用桥接）、当前仅适合受控私有预览而非公开云生产。若你的部署场景正好是"给少数可信账号复用 Codex 订阅"，可直接按本文的本地步骤验证三条路径；若目标是多租户公开服务，则应以"专用非特权桥接 + owner 路由"作为后续改造方向。

创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考