Summary
Support a ChatGPT/Codex subscription-backed provider path for Grida Desktop, where the user connects an existing OpenAI subscription and Grida continues to run its own agent loop, sessions, tools, and harness.
This is a different product/runtime path from ACP. ACP lets Grida drive an external agent. This issue is about using a user's existing subscription as the model/auth provider for Grida's own agent.
Why
Many prospective users already pay for ChatGPT Plus/Pro/Enterprise. Letting them plug in that existing subscription is a strong GTM path for Grida Desktop: users can try and adopt the local agent without first accepting a new Grida AI subscription, and Grida does not currently offer a free trial.
This should be treated as a first-class provider option, similar in spirit to connecting an API key or endpoint, but backed by a real subscription token flow instead of a static developer key.
Why Codex specifically
Codex appears to support a real auth/token flow that can be integrated without giving up control of Grida's agent loop. That means Grida can keep its existing tools, sessions, runtime harness, permissions, and UX instead of re-exposing everything back to an external ACP agent through MCP.
Codex also appears to have access to image generation internally. In ACP usage, asking Codex to generate an image works even though the tool is not surfaced as a normal public model-provider capability. We have not yet validated whether the same behavior is available through a subscription-backed provider path, so this should be treated as a research/compatibility question rather than an assumption.
Product precedent
Zed is a useful product reference here because it separates these paths:
- Use an Existing Subscription documents ChatGPT Plus/Pro through Zed's ChatGPT Subscription provider, with OpenAI sign-in and no separate OpenAI API key.
- LLM Providers describes the provider path for Zed-owned AI features such as Zed Agent, Inline Assistant, Git commit generation, and thread summaries.
- External Agents documents the ACP boundary, where external agents run as separate processes and usually own auth, model selection, subscriptions, and configuration.
- Codex CLI - ACP Agent documents Codex as an ACP external-agent setup.
- Use Your ChatGPT Subscription in Zed explains the product split explicitly: users can sign in with ChatGPT for Zed's built-in agent, use Codex through ACP, run Codex CLI, or bring an OpenAI API key.
Grida should preserve that distinction rather than treating ACP as the only way to reuse an existing AI subscription.
Desired product shape
In onboarding and settings, users should see a direct option such as:
- Connect ChatGPT subscription
After connecting, Grida should:
- Resolve Codex/ChatGPT subscription as a provider for Grida-owned agent runs.
- Keep Grida's existing agent loop and tools active.
- Store subscription credentials through the daemon/secrets boundary, not renderer state.
- Surface auth state, quota/cap failures, and fallback choices clearly.
- Allow fallback to Grida Gateway, API-key/BYOK providers, or local endpoints when the subscription path is unavailable.
Runtime boundary
This provider should not be modeled as an ACP agent provider.
ACP is useful when an external agent owns the loop. This issue is for the opposite boundary: Grida owns the loop, and the connected subscription supplies model access.
Implementation should likely introduce or clarify a provider/auth class distinct from:
- API-key BYOK providers
- OpenAI-compatible endpoint providers
- Grida Gateway
- ACP agent providers
Possible internal naming could be subscription-backed provider, OAuth-backed provider, or ChatGPT subscription provider.
Relationship to ACP
Grida initially explored ACP because subscription-backed first-party provider access was not known to be viable, and because existing CLI adoption, especially Claude Code, made ACP attractive as an integration path.
If the subscription-backed Codex path works, ACP should probably become secondary, advanced, or harder to find in the main onboarding flow. In particular, Claude should not remain the default first-run agent path if the product goal is for Grida to own the agent.
That onboarding/removal/refactor work is related but separate. It should get its own issue/PR so this issue can stay focused on supporting the subscription-backed provider itself.
Open questions
- What is the officially supported local auth surface for ChatGPT/Codex subscription use in third-party desktop tools?
- Which models/capabilities are available through the subscription-backed path?
- Does image generation work through this path, or only through ACP/Codex's external agent runtime?
- What quota/rate-limit signals can Grida receive and present to the user?
- What refresh-token lifecycle and storage requirements apply?
- How should this provider appear in the model picker relative to GG, BYOK, local endpoints, and ACP agents?
Related
Summary
Support a ChatGPT/Codex subscription-backed provider path for Grida Desktop, where the user connects an existing OpenAI subscription and Grida continues to run its own agent loop, sessions, tools, and harness.
This is a different product/runtime path from ACP. ACP lets Grida drive an external agent. This issue is about using a user's existing subscription as the model/auth provider for Grida's own agent.
Why
Many prospective users already pay for ChatGPT Plus/Pro/Enterprise. Letting them plug in that existing subscription is a strong GTM path for Grida Desktop: users can try and adopt the local agent without first accepting a new Grida AI subscription, and Grida does not currently offer a free trial.
This should be treated as a first-class provider option, similar in spirit to connecting an API key or endpoint, but backed by a real subscription token flow instead of a static developer key.
Why Codex specifically
Codex appears to support a real auth/token flow that can be integrated without giving up control of Grida's agent loop. That means Grida can keep its existing tools, sessions, runtime harness, permissions, and UX instead of re-exposing everything back to an external ACP agent through MCP.
Codex also appears to have access to image generation internally. In ACP usage, asking Codex to generate an image works even though the tool is not surfaced as a normal public model-provider capability. We have not yet validated whether the same behavior is available through a subscription-backed provider path, so this should be treated as a research/compatibility question rather than an assumption.
Product precedent
Zed is a useful product reference here because it separates these paths:
Grida should preserve that distinction rather than treating ACP as the only way to reuse an existing AI subscription.
Desired product shape
In onboarding and settings, users should see a direct option such as:
After connecting, Grida should:
Runtime boundary
This provider should not be modeled as an ACP agent provider.
ACP is useful when an external agent owns the loop. This issue is for the opposite boundary: Grida owns the loop, and the connected subscription supplies model access.
Implementation should likely introduce or clarify a provider/auth class distinct from:
Possible internal naming could be subscription-backed provider, OAuth-backed provider, or ChatGPT subscription provider.
Relationship to ACP
Grida initially explored ACP because subscription-backed first-party provider access was not known to be viable, and because existing CLI adoption, especially Claude Code, made ACP attractive as an integration path.
If the subscription-backed Codex path works, ACP should probably become secondary, advanced, or harder to find in the main onboarding flow. In particular, Claude should not remain the default first-run agent path if the product goal is for Grida to own the agent.
That onboarding/removal/refactor work is related but separate. It should get its own issue/PR so this issue can stay focused on supporting the subscription-backed provider itself.
Open questions
Related