feat: support ChatGPT plans for model inference

[ygireesh]

What

Allow OpenDots users to authenticate with ChatGPT and use eligible Plus/Pro plan usage for text inference without an OpenAI API key. Existing API-key deployments remain supported.

Architecture

ChatGPT OAuth → protected server credential store → rotating-token refresh → TanStack AI Responses adapter → CopilotKit BuiltInAgent. The current OpenAI-compatible Chat Completions adapter remains available.

Safety and compatibility

• Tokens stay server-side; PKCE, state, nonce, and signed ID-token validation are used.
• Refreshes serialize within this server process and persist rotating credentials atomically, including recovery checkpoints.
• ChatGPT requests use store:false, stream through the public /v1/responses endpoint, preserve local tools across continuations, and never fall back to API-key billing automatically.
• Identity sign-in and plan-sharing consent are separate states. Plan use requires an eligible account and the direct-use scope.
• Existing API-key and custom OpenAI-compatible paths remain available. Voice continues using its separate Realtime API key. Spaces, tools, computers, Slack, scheduled tasks, and Learning continue through DotAgent.

Validation

• npm ci (Node 24): passed; 0 reported vulnerabilities.
• npm test: 38 files; 188 passed, 1 skipped (Windows-only symlink test).
• npm run typecheck: passed.
• npm run lint: passed.
• npm run build: passed; Vite reports the existing large-chunk warning.
• Changed-file Prettier check and git diff --check: passed. Repository-wide npm run check-format still reports 112 warnings in unchanged files.
• Live ChatGPT OAuth and real plan inference were not performed. Automated checks do not validate a real account or OpenAI deployment eligibility.

Known limitations before broader deployment

• The credential file is protected by owner/mode and symlink checks, but token contents are not encrypted at rest. Use an encrypted OS volume and a private data directory.
• The credential store has no interprocess lock. Run one OpenDots server process per credential directory.
• Remote VM/container OAuth callback behavior requires separate validation; these instructions target a local Windows host.

Automated coverage complete; live ChatGPT OAuth authorization still requires manual validation.

[JanSimeonMetzger]

I'd like to use the actual OpenDots application with an existing ChatGPT subscription, so this addresses an important use case. Adding the request here to keep the discussion with the existing implementation.

My intended workflow is to self-host OpenDots on a private VPS, open its normal UI from a laptop or phone, and sign in to the selected ChatGPT account without supplying an OpenAI API key or enabling separate model API billing. I want to keep the upstream UI and workflows and avoid maintaining a replacement application.

Could you and the maintainers clarify the supported path and acceptance criteria?

• Real account and remote-host validation: confirm eligible accounts, plan-sharing consent, login/refresh/logout, and the documented remote VM callback procedure with a real account. Passing mocked tests should remain distinct from a live verification.
• Remaining services and limits: document whether CopilotKit Intelligence remains required, where conversations and files live, and which existing features work. Voice currently needs a separate Realtime API key; it should remain clearly unavailable in a subscription-only configuration unless a supported route is established. Subscription sign-in alone should not imply Codex Cloud execution or cloud-hosted files.
• Account isolation: keep credentials, histories, files, permissions, and learning data separate for each account/workspace or deployment. Never switch accounts or fall back to API-key billing automatically.
• Small, reusable integration: preserve the existing OpenDots architecture and use an explicit provider/auth configuration boundary, leaving room for other providers only when their subscription sign-in routes are supported. Compatibility with their native skills, plugins, tools, and approval rules needs an explicit assessment; it should not be assumed.

The official Sign in with ChatGPT registration guide, self-hosted VM guide, and preview limitations seem relevant. I have not live-tested this PR and am not claiming feature parity.

Is this PR the intended upstream direction for that workflow, and what still needs validation before it can be recommended?

[ygireesh]

Thanks — this is a very useful framing of the intended use case.

A couple of clarifications on the current state of this PR:

First, this has not been live-tested yet. The PR is intentionally still in Draft. The automated tests cover OAuth state/PKCE/ID-token validation, token refresh/rotation, Responses API request shaping, model discovery, local OpenDots tool execution, and ensuring ChatGPT-plan failures never fall back to OPENAI_API_KEY. However, we have not yet completed a real ChatGPT Plus/Pro authorization or real plan-backed inference request, so I’m not claiming production readiness or feature parity yet.

The current implementation is primarily aimed at the local/self-hosted flow where the browser and OpenDots process share the same machine. Your VPS workflow needs one additional piece. OpenAI’s documented VM flow requires completing OAuth locally because the 127.0.0.1 callback resolves on the browser machine, then securely transferring the protected credentials to the VM while preserving a distinct VM host ID. This PR currently documents that limitation, but does not yet provide an in-app VM credential-import/host-ID workflow. So I would not currently recommend this PR for the exact laptop/phone → remote VPS sign-in flow without that additional work.

On the other points:

• CopilotKit Intelligence is still required by the current OpenDots architecture for Threads/conversation persistence. This PR only replaces the text-model credential path; it does not remove Intelligence.
• Conversation history and local workspace data remain separate: conversation history stays in the configured Intelligence project, while Spaces/pages/workspace metadata remain in OpenDots’ local SQLite storage.
• Voice is unchanged and still requires the existing Realtime API credentials. ChatGPT plan sharing here only covers eligible Responses API text inference.
• This does not provide ChatGPT conversation history, ChatGPT plugins, Codex Cloud execution, or cloud-hosted OpenDots files. The token-sharing flow grants permission for eligible model inference only; it does not expose the user’s ChatGPT conversations or other account context.
• There is no automatic API-billing fallback. If chatgpt-plan is the selected provider and the plan request fails or reaches its limit, OpenDots stops and asks the user to reconnect or explicitly switch providers.
• The provider boundary is intentionally small. The existing CopilotKit → TanStack AI → OpenDots tool architecture is preserved. The ChatGPT path swaps only the model transport/authentication layer to OAuth + Responses API.
• Local OpenDots tools are preserved through function/custom tool calls. Automated tests now exercise a real OpenDots page tool round-trip through the Responses adapter, but live compatibility with every OpenDots workflow — Learning, scheduled work, Slack, computer tools, etc. — still needs connected-service validation. OpenAI’s preview also has limitations around several hosted Responses tools, so those should not be assumed to come from the user’s ChatGPT subscription.

The current acceptance criteria I’d use before moving this out of Draft are:

1. real eligible ChatGPT Plus/Pro login succeeds;
2. plan-sharing consent and model discovery work;
3. text inference works with OPENAI_API_KEY completely absent;
4. an actual OpenDots local tool call completes end-to-end;
5. restart + token refresh work;
6. logout/revocation behavior is verified;
7. plan failures are confirmed not to fall back to API billing;
8. then separately validate/document the remote-VM credential-transfer path.

So I see this PR as a candidate implementation of that direction, but not something I’d recommend yet. The next step is real-account validation, and the remote-VPS workflow needs explicit validation/UX before we can claim support for it.

I’d also welcome maintainer guidance on whether this provider boundary and VM workflow match the direction you’d want upstream.

[ArtuArtaza]

Doesn't make sense to keep this as env variables?

[ygireesh]

Good question. I actually considered making these configurable, but kept them fixed for now because this provider is specifically implementing OpenAI’s Sign in with ChatGPT flow, and those two values are part of that protocol rather than normal deployment configuration.

The separate OpenAI-compatible/API-key path is still configurable through OPENAI_BASE_URL, so custom providers remain supported there.

My thinking was that keeping the OAuth issuer/resource fixed reduces the chance of accidentally sending auth/token traffic to the wrong endpoint. For tests, we can still mock the network layer without exposing them as runtime env vars.

That said, if you have a deployment case where making them env-configurable would be useful, happy to adjust it.

[jerelvelarde]

This offers useful opt-in template value: server-side ChatGPT authorization and plan inference while retaining explicit API-key/provider choice, with no automatic billing fallback. The implementation validates PKCE/state/nonce and signed identity tokens, serializes refreshes in one process, persists rotating credentials atomically, protects token files, and sanitizes provider failures. The description accurately calls out unencrypted token storage, the single-process constraint and unverified remote callback/live account behavior.

Keep this as a draft. Credential-free focused tests pass all 41 cases across auth flow/refresh/store, plan request, research and TanStack integration. A further signed-token checkpoint/restart fixture reproduces the scope-check omission described inline; its consequence is one locally dispatched request after direct-use permission disappears, not demonstrated successful unauthorized inference. Original tests passed with canonical TMPDIR=/private/tmp; /tmp itself is a macOS symlink rejected by the intended credential-directory protection.

The request shape follows the documented preview: stream:true/store:false, public Responses endpoint, model visibility filtering, and local function tools through additional_tools are supported. See official sign-in requirements, models and inference, and preview limitations. Mocks do not establish actual Plus/Pro eligibility or deployment enablement. Before readying, fix the recovery consent gate, complete live authorization/plan inference and supported deployment validation, and resolve substantial production conflicts with current main 210a687 (configuration, dialog, agent setup and research) before rerunning the repository gates. Full repository gate results are recorded separately by the coordinating reviewer; encrypted reasoning/HITL continuation and live UI/provider behavior were not independently established by this focused review.

[jerelvelarde]

[P2] Recheck direct-use scope after recovering a refresh checkpoint

The checkpoint recovery path returns the newly installed token without checking its newly installed scopes. This is reachable when a legitimate refresh returns identity-only scopes plus a rotating token/ID token, ID-token verification temporarily fails because JWKS is unavailable, and the process retries or restarts. getValidAccessToken checks the old profile scopes before recovery; after Object.assign the return here bypasses the direct-use check in the normal refresh path. With the actual auth class, signed ID token, persisted file/restart and plan-fetch adapter, the diagnostic sends one Responses POST with the identity-only successor token while status already reports needsReconsent. This is a local consent/error-contract defect, not evidence of bypassing OpenAI server authorization. Preserve the rotated credentials, then require chatgpt.tokens.use.direct before returning any recovered token, and add the reduced-scope checkpoint regression.