ChatGPT subscription support through Codex app-server

[anotb]

I've built and tested an experimental Cloudflare OS runtime that uses the models included with a ChatGPT subscription without asking for an OpenAI API key. The implementation is available on this fork branch. It is a fork rather than a PR because the feature is larger than the repository's normal external-contribution limit.

The integration follows OpenAI's Codex as a platform direction and uses the official app-server protocol. It does not depend on the private chatgpt.com/backend-api/codex compatibility route.

Local experience

Run:

pnpm run-local:codex

Cloudflare OS starts with a Sign in with ChatGPT option in Add Model. After the one-time sign-in, it discovers the visible subscription model catalog and makes those models available in workspaces. There is no API URL, API key, or separate usage setup.

In a fresh workspace, GPT-5.6 Sol created a Tiny Counter gadget, wrote server.js, client.js, and README.md, then used the gadget twice to verify the persisted 0 → 1 → 0 flow. The model picker in the screenshot is the catalog returned by app-server for the signed-in account.

Runtime shape

App-server manages threads, turns, streamed items, tool calls, approvals, and account sign-in. Treating it as another OpenAI-compatible endpoint would hide those semantics, so the fork adds a narrow AgentRuntime seam:

Cloudflare OS chat and tools
        |
        +-- existing pi runtime
        |
        +-- Codex runtime -> official app-server -> ChatGPT subscription

The Codex runtime maps Cloudflare OS chat to thread/start and thread/resume, user messages to turn/start, streamed app-server items to existing AiChatStreamEvents, and Cloudflare OS tools to app-server dynamic tool calls. Cloudflare OS still executes its tools and persists its own chats and gadgets.

Deployment options tested

The local single-tenant path is implemented. A launcher supervises app-server beside Cloudflare OS, stores the ChatGPT login in an isolated persistent Codex home, and uses a loopback WebSocket listener with a short-lived capability token.

I also tested the boundary needed for a deployed Cloudflare OS instance. A temporary deployed Worker connected through a Cloudflare Quick Tunnel to the local app-server and successfully called initialize, account/read, and model/list; the account was reported as ChatGPT and returned eight visible models. A production version would use a named TLS tunnel and Access rather than a Quick Tunnel.

A fully hosted Container may also be possible. A temporary Container could reach both Codex endpoints and received ordinary JSON 401 responses, not the VPN/WAF block seen from direct Worker egress. I haven't tested authenticated app-server operation in a Container, and it adds questions around per-user credentials, storage, restarts, and isolation. The local companion is the simpler first deployment shape.

Scope and constraints

• The current implementation is explicitly single-tenant. Otherwise, every Cloudflare OS user would share one ChatGPT identity.
• The app-server home is separate from the user's normal Codex setup. The launcher disables inherited apps, plugins, and MCP dependency installation.
• The child process does not inherit OPENAI_API_KEY, CODEX_API_KEY, or CODEX_ACCESS_TOKEN, so this path cannot silently fall back to API billing.
• ChatGPT models use a chatgpt: profile namespace and do not collide with user-configured OpenAI models.
• App-server's WebSocket transport and dynamic tool API are experimental, so this remains an opt-in integration.
• ChatGPT plan limits still apply. This proposal does not add token-spend or subscription-accounting UI.

Questions

1. Is an opt-in, single-tenant app-server runtime in scope for Cloudflare OS?
2. Should the reusable AgentRuntime seam live under Support pluggable coding agent runtimes (Claude Agent SDK & Codex SDK) #78, with ChatGPT subscription support as one implementation?
3. For a deployed personal instance, does a local app-server behind Cloudflare Tunnel make sense as the supported shape, or is a per-user Container worth exploring now that Container egress appears viable?