Subscription Authentication Boundaries and ToS-Compliant Automation of Official CLI Coding Agents

Executive Summary

Every major AI lab now ships an official coding CLI — Claude Code, OpenAI's Codex CLI, Google's Gemini CLI — that authenticates against a consumer subscription and is explicitly designed to be scripted. That design choice creates a genuine ambiguity: subscriptions are priced and rate-limited around "ordinary, individual usage," but the same OAuth-authenticated client is also the sanctioned entry point for headless automation, CI pipelines, and long-running agents. Builders who want persistent, autonomous coding agents have to operate inside that ambiguity every day.

The boundary is not actually vague where it has been tested. Anthropic's own developer documentation states plainly that "advertised usage limits for Pro and Max plans assume ordinary, individual usage of Claude Code and the Agent SDK," and that OAuth authentication "is intended exclusively for purchasers of Claude Free, Pro, Max, Team, and Enterprise subscription plans" for use inside Anthropic's own applications — not third-party products (Claude Code legal and compliance docs). In February 2026, Anthropic tightened and clarified this further, stating that OAuth tokens obtained through consumer plans "in any other product, tool, or service — including the Agent SDK — [are] not permitted" (The Register). That single clause is the fault line between two visibly different worlds: proxies like CLIProxyAPI that extract OAuth tokens from official clients and re-serve them through an OpenAI-compatible API to unrelated consumers, versus builders who run the unmodified official binary, under their own account, to drive their own agent workloads.

This article maps that fault line: what the terms of service for Claude Code, Codex CLI, and Gemini CLI actually say; what enforcement has looked like in practice (bans, rate-limit changes, a class-action lawsuit, and a public standoff between Anthropic and third-party harness developers); a compliance spectrum from clearly legitimate to clearly violating; and architecture guidance for anyone building persistent or autonomous agents on top of these tools.

What the terms actually say

Anthropic. The Consumer Terms of Service prohibit accessing Anthropic's services "through automated or non-human means, whether through a bot, script, or otherwise," except through an API key or where explicitly permitted — and Claude Code itself is the explicit permission, since it is Anthropic's own product built for scripted use (autonomee.ai ToS explainer; Anthropic Consumer Terms updates). The line Anthropic actually enforces is narrower and more specific than "no automation": it is about which client is doing the automating. The legal-and-compliance page is unambiguous that OAuth is scoped to "Claude Code and other native Anthropic applications," and that anyone building a product or service — including with the official Agent SDK — must authenticate with an API key through the Claude Console instead, because "Anthropic does not permit third-party developers to offer Claude.ai login or to route requests through Free, Pro, or Max plan credentials on behalf of their users" (Claude Code legal and compliance docs). Anthropic frames its February 2026 update as a clarification of a policy that has existed since at least February 2024, not a new rule (The Register).

OpenAI. OpenAI's Terms of Service contain similar generic language against "automatically or programmatically" using or extracting from its services, which sits in obvious tension with a CLI that is inherently making programmatic requests (GitHub discussion, openai/codex #8338). Unlike Anthropic, OpenAI has not published an equivalent explicit clarification stating that ChatGPT-subscription OAuth is off-limits to third-party harnesses. If anything, the public signal has run the other way: Codex engineering lead Thibault Sottiaux publicly endorsed using Codex subscription tokens inside third-party harnesses, a position OpenAI took at the same moment Anthropic was shutting the same pattern down for Claude (The Register). Commentary in the developer community treats this as tolerance rather than sanction — "not proof of safety, it is proof OpenAI has tolerated some patterns while Anthropic actively did not" — and warns that as agentic usage scales, providers are more likely to tighten than loosen these policies (MindStudio).

Google. Gemini CLI's terms are closer to Anthropic's than to OpenAI's stated tolerance. Google's own developer documentation states that "using third-party software, tools, or services to harvest or piggyback on Gemini CLI's OAuth authentication to access backend services is a direct violation of Gemini CLI's applicable terms and policies," with enforcement escalating from rate adjustment to temporary pause to permanent account closure (google-gemini/gemini-cli ToS docs; Gemini API usage policies).

The shared structural pattern across all three vendors: automation through the official client, under your own subscription, is fine or explicitly designed-for. Automation that extracts the subscription's authentication and reuses it in a different client — even faithfully, even for personal use only, even without resale — is where Anthropic and Google's written terms turn from permissive to prohibited. OpenAI's terms read the same way on paper but the company's public conduct suggests looser de facto enforcement, at least as of mid-2026.

Enforcement reality

The clearest evidence of enforcement risk sits in the issue tracker of CLIProxyAPI itself, a Go proxy that harvests OAuth tokens from official CLI logins (Claude Code, Codex, Gemini CLI) and re-exposes them as an OpenAI-compatible API endpoint, enabling token reuse, multi-account pooling, and effectively resale of subscription quota to anyone who can reach the proxy. One reported ban carried the message "Your account has been disabled after an automatic review of your recent activities," directing the user to Anthropic's Trust & Safety appeal process, with no further detail on what triggered it (CLIProxyAPI issue #2211). A separate open issue on the project describes the underlying mechanism candidly: the proxy has no built-in rate limiting or per-client quota, so "a single key can exhaust all upstream credentials and cause permanent account bans," and the maintainers acknowledge the tool was designed for single-user or small trusted-team use without treating abuse-resistance as a baseline requirement for shared deployments (CLIProxyAPI issue #3467). A third issue shows Anthropic metering OAuth-proxied traffic as billable "extra usage" against a spending cap rather than counting it against the plan's included quota — evidence the provider can distinguish proxied traffic from native-client traffic at the billing layer, not just the ban layer (CLIProxyAPI issue #2599).

This culminated in a public confrontation in January–February 2026. Anthropic blocked OpenCode — a popular open-source, multi-model coding harness — and other third-party tools from authenticating with Claude subscription OAuth. Anthropic engineer Thariq Shihipar explained the rationale directly: third-party harnesses "generate unusual traffic patterns without any of the usual telemetry that the Claude Code harness provides, making it really hard for us to help debug when they have questions about rate limit usage or account bans" (The Register). Anthropic's argument, as reported, was also that these tools were "spoofing" Claude Code's client identity — sending headers that made Anthropic's servers believe requests originated from the official binary — and that newer OAuth tokens are scoped so they only function when Anthropic can verify the caller is the genuine Claude Code client rather than a harness replaying its headers (ZBuild). OpenCode subsequently removed support for Claude Pro/Max account keys and Claude API keys, citing Anthropic legal requests, while OpenAI publicly partnered with OpenCode as a competitive response (The Register).

Beyond token-harvesting proxies, Anthropic has also throttled pure over-usage on its own native client. In August 2025 it introduced weekly rate limits on top of existing five-hour rolling windows, citing "a small share of power users... running 24-hour sessions, sharing credentials across teams, and burning thousands of dollars of compute on $20 subscriptions" (TechCrunch; Stark Insider). Anthropic said the change affected under 5% of subscribers, but by June 2026 a proposed class action (Kahn v. Anthropic, N.D. Cal.) alleged the advertised "5x" and "20x" usage multipliers on Max plans were illusory once the weekly cap kicked in — one plaintiff reported a single five-hour session consuming 15% of his weekly allotment (Engadget). This matters for the automation question because it shows the rate-limit boundary is contested and moving even for fully compliant, native-client usage — "ordinary individual usage" is not a fixed, published number.

At the account-suspension level generally, Anthropic's own Transparency Hub reported banning roughly 1.45 million accounts across Claude.ai, the API, and Claude Code combined in the second half of 2025, receiving about 52,000 appeals and overturning only 1,700 of them — a 3.3% success rate (BigGo Finance). The company states the large majority of these are automated detections of clear abuse or ToS violations rather than mistaken bans of ordinary subscribers, and it commits to pro-rata refunds when a suspension turns out to be a billing error or false positive rather than a policy violation (support.claude.com appeals article). Independent reports of real false-positive suspensions do exist — including a case where a plan-upgrade or payment-method change alone appeared to trigger an automated security ban with no underlying misuse (GitHub, anthropics/claude-code#40046) — a useful reminder that the enforcement system is imperfect and probabilistic, not a precise ToS-violation detector.

The compliance spectrum

Laid end to end, the evidence supports a five-point spectrum rather than a binary:

Clearly compliant — interactive official client. A human runs Claude Code, Codex CLI, or Gemini CLI interactively, under their own subscription. Undisputed by any vendor.
Clearly compliant — official headless and SDK entry points. All three vendors ship sanctioned non-interactive modes: Claude Code's -p/print mode with --output-format json and --permission-mode flags for unattended runs (Claude Code headless docs), the official anthropics/claude-code-action for GitHub Actions (which explicitly supports authenticating with a Pro/Max subscription via a locally generated CLAUDE_CODE_OAUTH_TOKEN, alongside API-key and Workload Identity Federation options for enterprise use) (claude-code-action setup docs), and comparable CI-oriented modes for Codex CLI and Gemini CLI. Because the provider itself built and documents these unattended paths, running them — even 24/7, even without a human present — is inside the compliance boundary as written. This is the single most important fact separating "automation" from "abuse": the providers do not prohibit automation, they prohibit automation through a different, unauthorized client.
Gray zone — unattended driving of a consumer-subscription client at scale. This is where most serious agent builders actually operate: the genuine, unmodified official binary, authenticated with the owner's own OAuth, kept running or resumed continuously, sometimes across several parallel local sessions (a documented and vendor-acknowledged pattern — Claude Code even ships an experimental "agent teams" mode for running multiple sessions in tmux panes under one subscription (Claude Code agent-teams docs)). Nothing here involves token extraction, spoofing, or resale. But it sits directly on top of the language that "advertised usage limits... assume ordinary, individual usage" (Claude Code legal and compliance docs), and it is the exact behavioral pattern — near-continuous sessions, unusual duration and cadence — that Anthropic cited as the reason for introducing weekly rate limits in the first place (TechCrunch). A fully compliant auth chain can still look anomalous to a rate- or behavior-based anti-abuse system, and third-party writeups (unverified against Anthropic's own engineering documentation, so treated here as plausible rather than confirmed) describe detection layers that go beyond simple request counting — client-fingerprint validation, User-Agent analysis, and behavioral pattern matching, with some claiming TLS-fingerprint mismatches (a client claiming a browser User-Agent while its TLS handshake fingerprints as a bare HTTP library) as a bot-detection signal used broadly in the industry (bot-detection patent, USPTO; commentary in augmunt.com). The practical implication: staying in the "clearly compliant" tier of the client is necessary but not sufficient — usage pattern is a second, independent axis of risk.
Clearly violating — token extraction and multi-account pooling. Tools like CLIProxyAPI that log in as the official client purely to harvest the resulting OAuth token, then replay that token from a different process (often for many accounts simultaneously) to serve requests to third parties, sit unambiguously on the wrong side of Anthropic's, and probably Google's, written policy — and the ban reports in CLIProxyAPI's own issue tracker confirm this is enforced in practice, not just theoretical.
Clearly violating — client spoofing and quota resale. The most aggravated pattern: forging the official client's headers/telemetry to evade detection, and reselling pooled subscription quota as a general-purpose API to unrelated end users. This is functionally arbitrage of the gap between subscription and API pricing, and is the pattern Anthropic's February 2026 policy update and OpenCode's Claude-support removal were most directly aimed at.

Architecture guidance for agent builders

For anyone building a persistent or autonomous coding-agent system, the enforcement evidence above translates into concrete design rules:

Use the unmodified official binary or SDK, never a reimplementation or reverse-engineered protocol client. Do not strip, modify, or omit the telemetry headers the official client sends — this is precisely the signal Anthropic said it relies on to debug rate-limit and ban disputes, and its absence is also a detection signal in the other direction.
One human/subscription per agent identity. Do not centralize many users' work behind one subscription's OAuth token, even server-side and even for your own team — this is the redistribution/pooling pattern every vendor's terms name explicitly.
Prefer official headless/SDK/CI entry points over ad hoc scripting of the interactive client. claude -p, the Agent SDK with an API key, and the official GitHub Action are provider-sanctioned automation surfaces; treat them as the default rather than something to work around.
Switch from subscription to API/Commercial billing once usage stops looking like "ordinary individual usage." The economics differ sharply — Claude Max's $200/month 20x tier caps out far below its equivalent metered value (independent analysis has pegged full utilization at roughly $8,000/month in API-rate token spend) (search synthesis of SemiAnalysis Claude Max cost analysis) — but subscriptions are unmetered by design up to their cap, while API billing removes the ambiguity entirely: Anthropic's own compliance guidance states that "if you're using an API key, the restriction on automated access doesn't apply at all" (autonomee.ai). Production, multi-tenant, or revenue-generating workloads belong on API/Commercial Terms regardless of cost, both because that is what the terms require and because API access carries none of the consumer-account ban risk (family bans, no-warning suspensions, low appeal-success rates).
Pace and bound concurrency even when fully compliant. Because the gray zone is defined by pattern, not just protocol, avoid swarms of many parallel agent sessions on a single subscription running continuously with no idle periods; prefer bounded, resumable sessions over always-on daemons where the workload allows it, and expect that if a workload is inherently always-on, it is a candidate for API billing rather than subscription auth.
Do not build products that let other people's usage ride on your subscription, even indirectly (e.g., a hosted service where your Claude Code subscription serves multiple end users' requests). This is the wrapper/redistribution pattern Anthropic's Usage Policy separately restricts on the API side, and it is the commercial core of what subscription-scoped OAuth is defined to exclude (sitepoint.com, "The End of the Wrapper Era").

Broader context: why subscription arbitrage exists and where it's heading

Flat-rate coding-agent subscriptions are priced against a human-usage baseline — bursty, business-hours, interactive sessions — not against continuous machine consumption. When automation multiplies effective throughput by running 24/7, in parallel, or across pooled accounts, the unit economics invert: the same $200/month Max plan that comfortably covers a human's daily interactive use can represent thousands of dollars of equivalent API-metered value if driven continuously (aipricing.guru cost synthesis). This gap — not any single technical loophole — is the root cause of the entire token-harvesting-proxy ecosystem, and it is structurally the same tension "wrapper" SaaS products created on the API side, which Anthropic's revised Commercial Terms and Usage Policy have also moved to close on the redistribution front (sitepoint.com).

Providers are responding on three fronts simultaneously: contractual (explicit ToS clarifications scoping OAuth to native clients), technical (client-identity verification, rate/behavior-based anti-abuse systems, and — per industry-wide bot-defense trends outside the AI-CLI space specifically — a plausible future move toward hardware-backed device attestation such as Private Access Tokens) (dev.to bot-abuse overview), and pricing (weekly caps, metering proxied traffic as billable "extra usage" rather than included quota). Anthropic has moved furthest and fastest on all three axes; Google's written terms are comparably strict but with less public enforcement evidence surfaced so far; OpenAI's public posture has been the most tolerant of third-party harnesses to date, though commentators broadly expect the industry direction to be toward tighter, not looser, enforcement as agentic usage scales and the arbitrage gap becomes more visible to finance and product teams inside these companies.

Confidence and gaps

High confidence, directly sourced: the exact text of Anthropic's Claude Code legal-and-compliance page and its OAuth-scoping language (fetched directly from code.claude.com); the February 2026 Register reporting on Anthropic's ToS clarification and the Shihipar quote; the August 2025 weekly-rate-limit rollout and its stated rationale (TechCrunch, Stark Insider); the CLIProxyAPI ban and rate-limiting issues (read directly from the project's GitHub tracker); the Kahn v. Anthropic lawsuit filing details; the Gemini CLI ToS language on OAuth harvesting; and Anthropic's Transparency Hub ban/appeal statistics.

Lower confidence, treated as plausible inference rather than verified fact: the specific technical mechanics of anomaly detection (TLS fingerprint mismatches, exact header-based client verification logic) come from third-party blog commentary and SEO-oriented "ban survival guide" sites reverse-engineering observed behavior, not from Anthropic, OpenAI, or Google engineering documentation — these vendors do not publish their detection heuristics, for obvious reasons, so any description of how detection works is necessarily inferential. Similarly, the claim that 24/7 unattended driving of an otherwise-compliant official client carries residual ban risk is a synthesis of adjacent evidence (the "ordinary individual usage" contract language, the stated rationale for weekly limits, and general bot-detection literature) rather than a single documented case of a fully compliant, non-pooled, non-spoofed automation setup being banned purely for uptime. No such case was found in the available reporting — the documented bans are consistently tied to third-party harnesses, token proxying, or credential sharing, not to bare continuous use of the genuine client under a single owner's account. OpenAI's Codex-specific written policy on this exact question is comparatively undocumented; the analysis above relies more on OpenAI's public conduct and statements than on codified terms, which is itself a meaningful and noted asymmetry between the two companies' approaches.