OAuth in OpenClaw: Token Exchange, Storage, and Multi-Account Patterns
Learn how OpenClaw handles OAuth token exchange via PKCE, secure token storage, and multi-account management for providers like OpenAI Codex and Anthropic Claude CLI. Essential for developers integrating subscription-based auth.
Read this when
- You want to understand OpenClaw OAuth end-to-end
- You hit token invalidation / logout issues
- You want Claude CLI or OAuth auth flows
- You want multiple accounts or profile routing
OpenClaw supports OAuth ("subscription auth") for providers that offer it, notably OpenAI Codex (ChatGPT OAuth) and Anthropic Claude CLI reuse. For Anthropic, the practical split is:
- Anthropic API key: normal Anthropic API billing.
- Anthropic Claude CLI / subscription auth inside OpenClaw: Anthropic staff told us this usage is allowed again, so OpenClaw treats Claude CLI reuse and
claude -pusage as sanctioned for this integration unless Anthropic publishes a new policy. For Anthropic in production, API key auth is still the safer recommended path.
OpenClaw stores both OpenAI API-key auth and ChatGPT/Codex OAuth under the canonical provider id openai. Older openai-codex:* profile ids and auth.order.openai-codex entries are legacy state repaired by openclaw doctor --fix; use openai:* profile ids and auth.order.openai for new config.
This page covers:
- how the OAuth token exchange works (PKCE)
- where tokens are stored (and why)
- how to handle multiple accounts (profiles + per-session overrides)
Provider plugins that ship their own OAuth or API-key flow run through the same entry point:
openclaw models auth login --provider <id>
The token sink (why it exists)
OAuth providers commonly mint a new refresh token on every login or refresh. Some providers invalidate the previous refresh token when a new one is issued for the same user or app. Practical symptom: log in via OpenClaw and via Claude Code or Codex CLI, and one of them randomly gets logged out later.
To reduce that, OpenClaw treats the auth profile store as a token sink:
- the runtime reads credentials from one place per agent
- multiple profiles can coexist and route deterministically
- external CLI reuse is provider-specific: once OpenClaw owns a local OAuth profile for a provider, the local refresh token is canonical. If that local refresh token is rejected, OpenClaw reports the profile for re-authentication instead of falling back to external CLI token material. Codex CLI bootstrap is narrower still: it can only seed an empty
openai:default-style profile before OpenClaw owns OAuth for that provider; after that, OpenClaw-owned refreshes stay canonical - status or startup paths scope external CLI discovery to the provider set already configured, so an unrelated CLI login store is not probed for a single-provider setup
Storage (where tokens live)
Secrets live per agent, keyed by the logical name auth-profiles.json (the underlying store is the agent's SQLite database; the JSON name is kept for compatibility and tooling display):
- Auth profiles (OAuth + API keys + optional value-level refs):
~/.openclaw/agents/<agentId>/agent/auth-profiles.json - Legacy compatibility file:
~/.openclaw/agents/<agentId>/agent/auth.json(staticapi_keyentries are scrubbed when discovered)
Legacy import-only file (still supported, but not the main store):
~/.openclaw/credentials/oauth.json(imported into the auth profile store on first use)
All of the above also respect $OPENCLAW_STATE_DIR (state dir override). Full reference: /gateway/configuration-reference#auth-storage
For static secret refs and runtime snapshot activation behavior, see Secrets Management.
When a secondary agent has no local auth profile, OpenClaw uses read-through inheritance from the default or main agent store; it does not clone the main agent's store on read. OAuth refresh tokens are especially sensitive: normal copy flows skip them by default because some providers rotate or invalidate refresh tokens after use. Configure a separate OAuth login for an agent when it needs an independent account.
Anthropic Claude CLI reuse
OpenClaw supports Anthropic Claude CLI reuse and claude -p as a sanctioned auth path. If you already have a local Claude login on the host, onboarding or configure can reuse it directly. Anthropic setup-token remains available as a supported token-auth path, but OpenClaw prefers Claude CLI reuse when it is available.
Warning
Anthropic's public Claude Code docs say direct Claude Code use stays within Claude subscription limits, and Anthropic staff told us OpenClaw-style Claude CLI usage is allowed again. OpenClaw therefore treats Claude CLI reuse and
claude -pusage as sanctioned for this integration unless Anthropic publishes a new policy.For Anthropic's current direct-Claude-Code plan docs, see Using Claude Code with your Pro or Max plan and Using Claude Code with your Team or Enterprise plan.
If you want other subscription-style options in OpenClaw, see OpenAI Codex, Qwen Cloud Coding Plan, MiniMax Coding Plan, and Z.AI / GLM Coding Plan.
OAuth exchange (how login works)
OpenClaw's interactive login flows are implemented in openclaw/plugin-sdk/llm.ts and wired into the wizards and commands.
Anthropic setup-token
Flow shape:
- create the token by running
claude setup-tokenon any machine with Claude Code, then start Anthropic setup-token or paste-token from OpenClaw - OpenClaw stores the resulting Anthropic credential in an auth profile
- model selection stays on
anthropic/... - existing Anthropic auth profiles remain available for rollback or order control
OpenAI Codex (ChatGPT OAuth)
OpenAI Codex OAuth is explicitly supported for use outside the Codex CLI, including OpenClaw workflows.
The login command uses the canonical OpenAI provider id:
openclaw models auth login --provider openai
Use --profile-id openai:<name> for multiple ChatGPT or Codex OAuth accounts in one agent. Do not use openai-codex:<name> for new profiles. Doctor migrates that older prefix to a collision-free openai:* profile id; run openclaw models auth list --provider openai after repair before copying profile ids into auth.order or /model ...@<profileId>.
Flow shape (PKCE):
- generate a PKCE verifier or challenge and a random
state - open
https://auth.openai.com/oauth/authorize?...(scopeopenid profile email offline_access) - try to capture the callback on
http://localhost:1455/auth/callback(the callback host defaults tolocalhostand only accepts loopback hosts; override withOPENCLAW_OAUTH_CALLBACK_HOST) - if you can paste a code before the callback lands (or you are remote or headless and the callback can't bind), paste the redirect URL or code instead. Manual paste races the browser callback and whichever completes first wins.
- exchange the code at
https://auth.openai.com/oauth/token - extract
accountIdfrom the access token and store{ access, refresh, expires, accountId }
Wizard path is openclaw onboard to auth choice openai.
Refresh + expiry
Profiles store an expires timestamp. At runtime:
- if
expiresis in the future, use the stored access token - if expired, refresh (under a file lock) and overwrite the stored credentials
- if a secondary agent reads an inherited main-agent OAuth profile, the refresh writes back to the main agent store instead of copying the refresh token into the secondary agent store
- externally managed CLI credentials (Claude CLI, narrow Codex CLI bootstrap; see The token sink) are re-read instead of spending a copied refresh token. If a managed refresh fails, OpenClaw reports the affected profile for re-authentication instead of returning external CLI token material.
The refresh flow is automatic; you generally do not need to manage tokens manually.
Multiple accounts (profiles) + routing
Two patterns:
1) Preferred: separate agents
If you want "personal" and "work" to never interact, use isolated agents (separate sessions, credentials, and workspace):
openclaw agents add work
openclaw agents add personal
Then configure auth per agent (wizard) and route chats to the right agent.
2) Advanced: multiple profiles in one agent
The auth profile store supports multiple profile IDs for the same provider. Pick which one is used:
- globally via config ordering (
auth.order) - per-session via
/model ...@<profileId>
Example (session override):
/model Opus@anthropic:work
List existing profile IDs with:
openclaw models auth list --provider <id>
Related docs:
- Model failover (rotation and cooldown rules)
- Slash commands (command surface)
Related
- Authentication - model provider auth overview
- Secrets - credential storage and SecretRef
- Configuration Reference - auth config keys