Support ChatGPT subscription (Codex OAuth) as a model provider — pi-ai already ships the client

[kei-tenkawa]

The "Add Model" flow currently requires an API key for every provider. Many users already pay for a ChatGPT subscription, and OpenAI now openly tolerates third-party use of Codex OAuth (they open-sourced a plugin calling Codex from Claude Code, and enabled OAuth for OpenClaw). Platforms like exe.dev already offer "connect your ChatGPT subscription" as a first-class model source.

Notably, @earendil-works/pi-ai 0.83.0 — already vendored here — ships everything needed: api/openai-codex-responses (speaks to chatgpt.com/backend-api, WebSocket + SSE fallback, auth via access token + chatgpt-account-id) and the openai-codex model catalog. The wiring in ai-models.ts (API_STREAMS / catalogModel / a direct-path handle) looks thin.

The design questions would be: (1) the "Sign in with ChatGPT" OAuth flow and refresh-token custody — presumably a DO, following the same pattern as the Cloudflare gatekeeper's OAuth; (2) subscription traffic bypassing AI Gateway cost accounting.

Would love to see this in-tree someday!

[manojitballav]

Would this design be generalized for other subscription providers ?

[acomagu]

I forked and tried adding ChatGPT OAuth implementation, but can't call chatgpt.com/backend-api. They always returns error response: If you are using a VPN, try turning it off. [ IP:XXXX:XXXX:XXXX:XXXX | Ray ID: ... ]

So I guess their WAF blocks Cloudflare Workers IP.

[anotb]

I tested both the compatibility-gateway path and the new official Codex app-server path against a local Cloudflare OS checkout.

The gateway works today with Cloudflare OS's existing OpenAI Responses provider, including real tool calls, Gadget creation, and reload persistence. But it depends on the private chatgpt.com/backend-api/codex contract.

The more durable direction now looks like codex app-server, which OpenAI explicitly positions as the product-integration protocol in Codex as a platform. With @openai/codex 0.149.1 and ChatGPT subscription auth, I verified:

• account/read reported managed ChatGPT auth without exposing credentials.
• model/list returned the subscription's full visible Codex model catalog, rather than one hard-coded gateway model.
• A host-owned dynamic tool was called successfully.
• After stopping and starting a new app-server process, thread/resume restored the same durable thread and the tool remained callable.

This is not really another AiModelProvider: app-server owns the thread/turn/tool lifecycle. The clean Cloudflare OS seam seems to be an AgentRuntime abstraction, keeping the existing pi runtime as the default and adding an experimental Codex runtime that maps:

• OS chat to thread/start / thread/resume
• user turns to turn/start / turn/interrupt
• app-server deltas to the existing AiChatStreamEvent stream
• Cloudflare OS tools to experimental dynamicTools / item/tool/call

A tiny local companion is still necessary because a Worker cannot launch the Codex process. It would only own app-server's stable stdio JSONL process and managed ChatGPT login; the runtime adapter, durable chat mapping, tool execution, and approvals would live in Cloudflare OS. For a deployed OS, that companion could remain local behind an authenticated named Cloudflare Tunnel, avoiding the Workers-egress WAF failure already reported above.

Would maintainers be interested in this AgentRuntime direction (related to #78) before a larger implementation PR is opened? I have the protocol proof and a one-click local onboarding prototype, but am deliberately not opening a feature-sized PR without alignment given the contribution policy.

[anotb]

One useful simplification after checking the current transport docs more closely: if an experimental MVP is acceptable, no custom HTTP/SSE companion is required. App-server already exposes an experimental WebSocket JSON-RPC transport and built-in capability-token / signed-bearer authentication.

That makes the lean boundary:

Cloudflare OS CodexAgentRuntime -> codex app-server WebSocket -> ChatGPT

For local OS, the runtime can connect to a loopback app-server listener. For deployed OS, the same authenticated listener can remain on the user's machine behind a TLS Cloudflare Tunnel. A tiny launcher/service may improve onboarding, but it does not need to translate protocols or own credentials; the official Codex process owns both.

The proposed OS-native runtime seam and the rest of the proof remain the same. This is experimental because app-server's WebSocket transport and dynamicTools are currently marked experimental, which seems reasonable for an opt-in first implementation while the new platform surface settles.

[anotb]

I built an experimental Cloudflare OS integration on this fork branch.

It uses OpenAI's official codex app-server, rather than the private chatgpt.com/backend-api/codex route used by the pi-ai approach. The normal Cloudflare OS agent loop remains unchanged for existing providers. ChatGPT subscription models use a small AgentRuntime seam that maps Cloudflare OS chat and tools to app-server threads and turns.

The parts I've verified are:

• pnpm run-local:codex starts Cloudflare OS and the local app-server. The Add Model screen offers ChatGPT sign-in without asking for an API key.
• After sign-in, Cloudflare OS discovered all eight visible models on the tested subscription instead of exposing one hard-coded model.
• GPT-5.6 Sol built a fresh Tiny Counter gadget, wrote its three files, and used the gadget to verify the persisted 0 → 1 → 0 flow.
• A temporary deployed Worker connected through a Cloudflare Quick Tunnel to the local app-server and completed initialize, account/read, and model/list.
• A temporary Cloudflare Container reached the Codex endpoints and received normal JSON 401 responses rather than the Worker-egress VPN/WAF response reported above. This only proves Container egress; I haven't tested an authenticated hosted app-server there.

The fork keeps this single-tenant. The launcher uses an isolated Codex home, disables inherited apps and plugins, removes API-key environment variables, and protects the local listener with a random capability token. A multi-user deployment would need one app-server identity per user rather than sharing the deployment owner's ChatGPT account.

I put the screenshots, deployment options, and open design questions in this separate discussion.