opencode-claude-auth: Reuse Your Claude Code Login Inside OpenCode
OpenCode plugin that uses your existing Claude Code credentials — no separate login needed.
At a glance
- What is it?
- An OpenCode plugin that reads your existing Claude Code OAuth credentials from the macOS Keychain or a credentials file, so you do not need a separate Anthropic API key or login. It is a thin, single-purpose bridge, and that narrowness is both the point and the limit.
- Who is it for?
- Adopt opencode-claude-auth if you already run Claude Code on the same machine and want OpenCode to use that session without pasting an API key. Skip it if you need a headless deployment with no Claude Code install, or if you want multi-account load balancing, which is what the CLIProxyAPI route is for.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 3 days ago.
- What is it written in?
- Mainly TypeScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap opencode-claude-auth fills
OpenCode needs Anthropic credentials to talk to Claude models. Claude Code already has them. Normally that means either pasting an API key into OpenCode or logging in twice, and the two credential stores drift apart. This plugin registers its own Anthropic auth provider inside OpenCode and pulls tokens from the Claude Code side, so the second login never happens.
The audience is narrow and specific: developers who already run Claude Code locally and want OpenCode as a second client against the same account. The README states the plugin is self-contained and that no builtin Anthropic auth plugin is required. If you do not have Claude Code installed and authenticated, there is nothing here for you, because the plugin has no login flow of its own.
How the credential interception actually works
The plugin registers an auth provider with a custom fetch handler that intercepts Anthropic API requests. Before a request goes out, it reads OAuth tokens from one of two sources, in order: the macOS Keychain, covering all Claude Code-credentials entries, then ~/.claude/.credentials.json as a fallback on any platform. If CLAUDE_CONFIG_DIR is set, the fallback path becomes $CLAUDE_CONFIG_DIR/.credentials.json instead.
Tokens are cached in memory with a 30-second TTL. When a token is near expiry, the plugin refreshes it directly against Anthropic's OAuth endpoint, which the README notes consumes zero LLM tokens. If that direct refresh fails, it falls back to invoking the claude CLI. Credentials are also synced into OpenCode's auth.json as a fallback, and on Windows the plugin writes to both %USERPROFILE%\.local\share\opencode\auth.json and %LOCALAPPDATA%\opencode\auth.json to cover different installation methods. A background re-sync runs every 5 minutes.
The design choice worth noting is the CLI fallback. It means the plugin can keep working when the OAuth endpoint path breaks, but it also means a refresh can spawn a process. The README does not document how long that fallback takes or whether it is retried.
Installing the plugin and running your first request
The prerequisite is Claude Code, installed and authenticated at least once by running claude. OpenCode must also be installed. macOS is preferred because it uses the Keychain; Linux and Windows work through the credentials file fallback.
Add the plugin to your OpenCode config at ~/.config/opencode/opencode.json:
{
"plugin": ["opencode-claude-auth@latest"]
}The README states that the @latest tag makes OpenCode pull the newest version on startup, and that no manual npm install is needed because OpenCode installs npm plugins with Bun at startup. After that, run OpenCode. The plugin handles auth automatically: it reads the Claude Code credentials, presents them to the Anthropic API, and refreshes them in the background. If your credentials are not OAuth-based, the README says the plugin falls through to standard API key auth.
On macOS with more than one authenticated Claude Code account, the plugin detects all of them from the Keychain and labels each by subscription tier. To pick one:
opencode auth loginSelect "Switch Claude Code account" and choose. The selection persists across sessions. If only one account is found, the README says the switcher is hidden and the plugin uses that account directly.
Where this plugin is the wrong tool
The plugin depends entirely on credentials that another program created. If Claude Code is not installed, or has never been run, there is no Keychain entry and no credentials file, and the failure message is "Credentials not found" with the README's own remedy of running claude first. That makes it a poor fit for CI containers, remote build agents, or any environment where you would rather provision a key than run an interactive login.
Platform behaviour is also uneven. The Keychain path is macOS-only; everywhere else the plugin reads a JSON file, and the README's troubleshooting row for Linux and Windows simply says to ensure ~/.claude/.credentials.json exists. There is no documented way to point the plugin at a credential store of your own choosing, beyond setting CLAUDE_CONFIG_DIR before Claude Code writes there.
Finally, the model list is fixed in the README at 14 entries, and the project ships a pnpm run test:models script to verify them against your account. That script is the honest signal here: the supported set is something you check, not something the plugin negotiates at runtime.
CLIProxyAPI, the heavier alternative
The README itself points at CLIProxyAPI as the alternative when the plugin is not required. The difference is architectural. CLIProxyAPI logs in to your Claude Code account with OAuth, owns token refresh, and exposes a Claude-compatible API on http://localhost:8317 by default. You then point OpenCode's built-in Anthropic provider at that base URL with an apiKey, and remove opencode-claude-auth from the plugin list, because the README says the two approaches should not be combined.
What you gain is a separate service that other clients can also hit, plus multi-account load balancing and support for other providers such as Codex, Gemini and Grok. What you pay is a running process, a config.yaml with an api-keys entry, and one more thing that can be down when you want to send a request. The README frames the plugin as the lighter option when all you need is Claude Code credentials inside OpenCode. That framing is fair, and it also tells you the plugin is not trying to be a gateway.
Maintenance, licence and what a version bump costs you
The repository is not archived, and the last push was on 2026-09-12. Releases are frequent and small: v2.1.5 on 2026-07-30, v2.1.6 on 2026-08-03, v2.2.0 on 2026-09-01. The CHANGELOG.md sits at the repository root, so version-to-version differences are traceable without reading commits.
Because the README recommends the @latest tag, OpenCode will pull the newest published version on startup rather than a version you pinned. That is convenient and it is also the upgrade cost: you are opting into whatever shipped most recently, and a regression in credential handling would surface on your next launch rather than at a moment you chose. Pinning a specific version in the plugin array is the obvious counterweight, though the README does not document that pattern or how OpenCode resolves a pinned specifier.
The package is MIT licensed, which permits commercial use and modification; the repository ships a LICENSE file at the root. That is a statement about the licence text, not advice about your situation. If you redistribute the plugin inside a product, read the file yourself.
Editorial conclusion
Adopt opencode-claude-auth if you already run Claude Code on the same machine and want OpenCode to use that session without pasting an API key. Skip it if you need a headless deployment with no Claude Code install, or if you want multi-account load balancing, which is what the CLIProxyAPI route is for. Before relying on it, run opencode auth login to confirm your accounts are detected, and check that the credential file or Keychain entry it reads actually exists on your platform.
Frequently asked questions
Does opencode-claude-auth need a separate Anthropic API key?
No. The plugin reads OAuth tokens from your Claude Code credentials and presents them to the Anthropic API, and the README states no separate login or API key is needed. If your credentials are not OAuth-based, the plugin falls through to standard API key auth.
Where does opencode-claude-auth read credentials from on Linux and Windows?
It reads ~/.claude/.credentials.json, or $CLAUDE_CONFIG_DIR/.credentials.json when that environment variable is set. The README's troubleshooting notes that if the file is missing, running claude creates it.
How do I switch between multiple Claude Code accounts in opencode-claude-auth?
On macOS the plugin detects all authenticated accounts from the Keychain and labels them by subscription tier. Run opencode auth login, select "Switch Claude Code account", and pick one; the README says the choice persists across sessions.
Community notes