Can You Ship the Claude Agent SDK in Your App? OAuth vs API Keys, and What Anthropic Actually Permits

Can You Ship the Claude Agent SDK in Your App?

If you're building a product on top of Claude Code, two questions come up early and get tangled together:

1. Can I bundle the Agent SDK — the actual binary — inside my app?
2. Can my app run on the customer's Claude Pro or Max subscription instead of making them paste an API key?

They feel like one question about "is this allowed." They aren't. One is a packaging question with no published restriction. The other is named and prohibited in plain language. Getting them backwards is how teams ship the wrong thing.

Here's the short version, then the receipts.

The short answer

Question	Answer
Bundle the SDK binary in your app	Not restricted. Nothing in the published terms addresses packaging or redistribution.
Use a customer's Pro/Max plan credential	Explicitly not permitted.
Use an API key the customer provides	The endorsed path.
Launch a Claude Code the user installed and authenticated themselves	Different architecture — you broker nothing. Still bound by the ordinary-usage clause.

Where the packaging assumption comes from

The confusion is easy to sympathize with. Open node_modules/@anthropic-ai/claude-agent-sdk/LICENSE.md and you get one sentence:

© Anthropic PBC. All rights reserved. Use is subject to the Legal Agreements outlined here.

"All rights reserved" pattern-matches to don't redistribute this, especially next to the MIT and Apache-2.0 licenses most npm dependencies carry. So teams assume shipping the binary is the risky part and go hunting for a way around it.

But that line is a pointer, not a grant or a prohibition. It resolves to Anthropic's Claude Code legal-and-compliance page — and that page is about who may authenticate and how. It does not mention redistribution, bundling, or embedding at all. It does the opposite of restricting third-party developers: it addresses them directly and tells them which auth method to use.

Meanwhile the SDK's own install mechanism ships a per-platform binary through npm optionalDependencies (claude-agent-sdk-darwin-arm64, -linux-x64, and so on). That is how a native dependency is normally distributed. If you npm install the SDK and package your app, the binary comes along — that's the designed behavior, not a loophole.

What is actually restricted

The operative passage, verbatim:

Developers building products or services that interact with Claude's capabilities, including those using the Agent SDK, should use API key authentication through Claude Console or a supported cloud provider. 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.

Note the two different strengths in one paragraph. Developers should use API keys — that's guidance. Anthropic does not permit offering Claude.ai login or routing plan credentials — that's a prohibition. Collapsing them into a single "you must use API keys" rule reads more restrictively than the text supports; treating the second as soft reads more permissively than it supports.

There's a second clause that matters just as much and gets quoted less:

Advertised usage limits for Pro and Max plans assume ordinary, individual usage of Claude Code and the Agent SDK.

That one isn't about identity at all. It's about volume and pattern.

The four architectures

Sort your design into one of these before writing code.

1. Your app collects and stores a plan token

The user signs into Claude through your UI, or pastes a subscription token, and you keep it — keychain, database, encrypted blob, doesn't matter. Your backend or your app then makes Claude requests with it.

This is the named restriction. You are offering Claude.ai login and routing requests through plan credentials on behalf of your users. Both halves of the prohibited sentence. It doesn't become permitted because the storage is local or the encryption is good — the issue is that your product is the party brokering the credential.

2. Your app takes an API key from the user

The user creates a key in the Claude Console (or Bedrock, or Vertex) and gives it to your app. You store it, you make the calls, they get the bill.

This is the endorsed path — it's the exact thing the terms tell developers to do. It's also what Cursor, Cline, Aider, and most of the BYOK tooling ecosystem does. The friction is real (a user has to go make a key, and API pricing is per-token rather than flat), and that friction is why teams keep looking for option 1. Take the friction.

3. Your app routes through a third-party gateway

An OpenRouter-style path, where the SDK's base URL points at a compatible endpoint and the user's own gateway account is billed.

Fine, and it sidesteps the question entirely — no Anthropic subscription credential is involved anywhere in the flow. Worth knowing that the Agent SDK reads ANTHROPIC_BASE_URL, so this is a configuration change rather than a rewrite.

4. Your app launches a Claude Code the user already installed

The user installed Claude Code themselves and authenticated it in their own terminal, under their own agreement. Your app resolves the binary on PATH and spawns it. The token stays in their keychain. Your code never reads it, never transmits it, never sees it.

This is materially different from option 1, and the difference is the phrase on behalf of their users. That describes a party that holds or brokers a credential. Here nobody brokers anything: the request originates on the user's machine, as the user, using software they installed and a session they opened.

It's also the only reading that stays self-consistent. Anthropic ships headless mode (claude -p) as a documented interface for exactly this — scripting and automation against an installed, authenticated CLI. If launching an already-authenticated binary counted as third-party credential routing, every shell script, Makefile, git hook, CI step, and editor task that calls claude would violate it too. That isn't a plausible reading of a feature Anthropic documents and supports.

What still binds this case is the other clause: ordinary, individual usage. One person driving their own machine interactively is ordinary. An unattended agent loop running overnight against a Max plan, or a shared workstation quietly serving a team, is where you'd draw attention — and that's a question about volume, not about who called spawn().

The practical consequence: you can drop ~200 MB

Once you know the packaging isn't the constrained part, the bundled binary becomes a plain engineering decision — and there's an easy win in it.

The Agent SDK exposes an option for exactly this:

pathToClaudeCodeExecutable — Path to the Claude Code executable. Uses the built-in executable if not specified.

Point it at a resolved user install and the bundled copy becomes dead weight. On macOS arm64 that binary is roughly 200 MB — frequently larger than everything else in an Electron app except the Chromium frameworks themselves.

A resolver is about fifteen lines: check a private install path, then command -v claude with an enriched environment, then fall back to the user's login shell so nvm and Homebrew installs resolve. Cache the result. If nothing is found, either prompt the user to install Claude Code or fall back to your API-key path.

One detail that bites: the SDK's platform package and Claude Code are version-pinned to each other, and they aren't the same build. Agent SDK 0.2.141 ships Claude Code 2.1.141; a user's own install might be 2.1.222 — different size, different hash, newer protocol. Running the SDK against a newer binary is normally fine, but it is version skew, so it belongs in your test matrix rather than in your assumptions.

What to do

• Don't build option 1. If you already shipped a plan-token path, that's the one to remove — not the bundled binary.
• Default to option 2, and treat the API-key setup step as onboarding to design well rather than a problem to engineer around.
• Offer option 4 as the power-user path. It's a better experience for developers who already live in Claude Code, and it takes a large chunk out of your download size.
• Check your marketing copy against your code. These drift independently. A pricing page describing "bring your own Claude Pro subscription" while the code brokers a plan token is the combination worth auditing first.
• Ask if you're near the line. The terms page ends with a pointer to contact sales for questions about permitted authentication. If your architecture is genuinely novel, a short email beats a confident guess.

The one-sentence version

Packaging the Claude Agent SDK isn't the restricted thing; routing someone's Pro or Max subscription through your product is — and if you were avoiding the bundle for licensing reasons, you were optimizing the wrong constraint.

---

This is a reading of Anthropic's published terms as of August 2026, not legal advice. Terms change; check the source before you ship.