Risk of using subscribed accounts (OAuth/Session Token) via opencodex under Providers' ToS

[NewLand-Ju]

I am considering using opencodex to connect subscribed accounts (via OAuth tokens or Web Session tokens) of services like Antigravity, Claude Pro/Team, or Grok to official agents/CLIs (e.g., Codex CLI, Claude Code, Cursor).

Before proceeding, I would like to ask about the potential risks regarding the Terms of Service (ToS) of model providers.

1. Risk of ToS Violations & Account Bans

• Connecting OAuth/Session tokens of paid subscription accounts through an unofficial local proxy (opencodex) to external clients—could this be flagged as reverse engineering, unofficial access, or rate-limit bypassing, leading to account suspension/bans by providers (Anthropic, OpenAI, Google, xAI, etc.)?

2. Risk Difference: Official API Key vs. Subscribed Account (OAuth Token)

• Is there a noticeable difference in risk (detection/penalties) between using official API keys versus forwarding OAuth/Session tokens from web/app subscriptions?

3. Recommendations & Best Practices

• Are there any known experiences, cautions, or recommended practices regarding this setup from the maintainer or community members?

• Thank you for your time and guidance!

[Wibias]

Hey @NewLand-Ju sorry for this later answer, i didnt know we had discussions enabled.

Good question. There is no blanket answer here because each provider has different terms and may change them over time.

In general, the safest option is always the provider's officially documented API/authentication method. Using an official API key is different from extracting or forwarding a consumer web/session token through another client.

Some subscriptions officially support OAuth authentication in their own CLIs. For example, Claude subscriptions can be used with Claude Code, and Antigravity CLI officially authenticates with Google OAuth. That does not necessarily mean the resulting token is authorised for arbitrary third-party clients or proxies.

OpenCodex itself does not bypass provider rate limits or guarantee that a particular authentication method complies with a provider's ToS. Users are responsible for checking the terms for the service and account type they connect.

I would especially avoid:

• extracting/reusing browser session tokens where the provider does not document that use
• sharing account credentials
• using authentication intended for one client as a general-purpose API credential without provider support
• attempting to bypass subscription, usage, or rate limits

roviders can restrict or terminate accounts for violations. OpenAI, for example, explicitly prohibits credential sharing, reverse engineering, and circumventing rate limits/restrictions, while its API is covered separately as a developer service. xAI goes even further and currently prohibits automated/non-human access to its consumer service, while its API is governed separately by its enterprise terms.

So my recommendation is: use official API keys or provider-documented OAuth flows where possible. If you use subscription/session credentials outside the client or workflow for which the provider documents them, treat that as unsupported unless the provider explicitly says otherwise.

I also can't give assurances about whether a provider will detect or penalise a particular setup. That is ultimately up to the provider.

The Chiefs of openai as well as of anthropic said on x that they would not ban user doing it. But thats ofc just a post on x.