Anthropic limits Claude Code Agent SDK to API-key paths, not Free/Pro/Max OAuth tokens
Anthropic’s Claude Code docs say consumer OAuth tokens from Free, Pro, and Max cannot be used with the Agent SDK, and staff said clearer guidance is coming. If you automate local dev loops or parallel workers, use API keys until the allowed auth patterns are explicit.
TL;DR
- Anthropic's compliance docs now state that OAuth tokens from Claude Free, Pro, or Max "are strictly for use with Claude Code and Claude.ai" and that using them in "other products, tool, or service — including the Agent SDK" violates the consumer terms.
- The policy matters because developers are already trying to use Claude Code subscriptions to power local automation and parallel workers; in Matt Pocock's thread, the concrete ask was whether a subscription OAuth token can back the Agent SDK for "a local dev loop" and open-source tooling.
- The implementation gap is narrow but important: the follow-up post says bash-scripted Claude Code use appears documented as acceptable, but using the Agent SDK from TypeScript for the same workflow may read as disallowed.
- Anthropic has not changed the rule publicly yet. Instead, staff said in the reply from trq212 that the guidance has been "confusing," that the Agent SDK spans many use cases, and that "more clarity" is coming.
What did Anthropic actually say?
Anthropic's Claude Code legal and compliance page draws a hard line between consumer and commercial auth. The page says developers should authenticate with API keys from the Claude Console or supported cloud providers, and separately says OAuth tokens from Free, Pro, or Max accounts cannot be used in other products or services, "including the Agent SDK." Docs excerpt
That is the key implementation detail for engineers building wrappers around Claude Code. If a tool is calling the Agent SDK, Anthropic's published guidance currently treats consumer OAuth as the wrong credential path, even when the underlying goal is still Claude-assisted coding rather than a public SaaS integration. Original question
Where is the ambiguity for Claude Code workflows?
The dispute is not about whether developers want to automate Claude Code; it's about which abstraction layers Anthropic considers equivalent. In the TypeScript example, Matt Pocock says he assumed running Claude Code inside a bash script was allowed because Claude Code documents scripting as an expected use case. He then asks whether moving the same local workflow into a TypeScript script via the Agent SDK would suddenly become a terms violation.
That distinction matters for real tooling. The thread's specific use case was "parallelizing multiple Claude Code's" and potentially distributing an open-source helper that makes that parallelization easier. Thread details Anthropic's wording leaves engineers with a split model: shelling out to Claude Code may appear acceptable, while using Anthropic's own SDK with a consumer OAuth token for the same local-dev loop appears prohibited.
What happens next?
Anthropic did not offer a definitive allowed-pattern matrix in public. Instead, trq212 replied that the situation has been "confusing," said the team should be clearer, and promised a follow-up because "the Agent SDK spans a lot of use cases." Reply text
A later follow-up from trq212 adds operational context rather than a product change: Anthropic says usage has grown quickly across Claude.ai, Claude Code, enterprise workflows, and the Agent SDK, and explicitly acknowledges, "We have not done fully right by Agent SDK users." That leaves the current state unchanged for now: the public docs point developers to API-key-based authentication, while staff have only committed to clarifying how Agent SDK use cases should be interpreted.