Skip to content

OAuth

OpenClaw supports “subscription auth” via OAuth for providers that offer it (notably OpenAI Codex (ChatGPT OAuth)). For Anthropic, the practical split is now:

  • Anthropic API key: normal Anthropic API billing
  • Anthropic Claude CLI / subscription auth inside OpenClaw: Anthropic staff told us this usage is allowed again

OpenAI Codex OAuth is explicitly supported for use in external tools like OpenClaw.

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.

For Anthropic in production, API key auth is the safer recommended path.

This page explains:

  • how the OAuth token exchange works (PKCE)
  • where tokens are stored (and why)
  • how to handle multiple accounts (profiles + per-session overrides)

OpenClaw also supports provider plugins that ship their own OAuth or API-key flows. Run them via:

Terminal window
openclaw models auth login --provider <id>

OAuth providers commonly mint a new refresh token during login/refresh flows. Some providers (or OAuth clients) can invalidate older refresh tokens when a new one is issued for the same user/app.

Practical symptom:

  • you log in via OpenClaw and via Claude Code / Codex CLI → one of them randomly gets “logged out” later

To reduce that, OpenClaw treats auth-profiles.json as a token sink:

  • the runtime reads credentials from one place
  • we can keep multiple profiles and route them deterministically
  • external CLI reuse is provider-specific: Codex CLI can bootstrap an empty openai:default profile, but once OpenClaw has a local OAuth profile, the local refresh token is canonical. If that local refresh token is rejected, OpenClaw reports the managed profile for re-authentication instead of using Codex CLI token material as a sibling runtime fallback. Other integrations can remain externally managed and re-read their CLI auth store
  • status and startup paths that already know the configured provider set scope external CLI discovery to that set, so an unrelated CLI login store is not probed for a single-provider setup

Secrets are stored in agent auth stores:

  • 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 (static api_key entries are scrubbed when discovered)

Legacy import-only file (still supported, but not the main store):

  • ~/.openclaw/credentials/oauth.json (imported into auth-profiles.json on first use)

All of the above also respect $OPENCLAW_STATE_DIR (state dir override). Full reference: /gateway/configuration

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/main agent store. It does not clone the main agent’s auth-profiles.json 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.

OpenClaw also exposes Anthropic setup-token as a supported token-auth path, but it now prefers Claude CLI reuse and claude -p when available.

OpenClaw supports Anthropic Claude CLI reuse again. If you already have a local Claude login on the host, onboarding/configure can reuse it directly.

OpenClaw’s interactive login flows are implemented in openclaw/plugin-sdk/llm and wired into the wizards/commands.

Flow shape:

  1. start Anthropic setup-token or paste-token from OpenClaw
  2. OpenClaw stores the resulting Anthropic credential in an auth profile
  3. model selection stays on anthropic/...
  4. existing Anthropic auth profiles remain available for rollback/order control

OpenAI Codex OAuth is explicitly supported for use outside the Codex CLI, including OpenClaw workflows.

The login command still uses the canonical OpenAI provider id:

Terminal window
openclaw models auth login --provider openai

Use `—profile-id openai:

for multiple ChatGPT/Codex OAuth accounts in one agent. Do not useopenai-codex:

for new profiles. Doctor migrates that older prefix to a collision-freeopenai:*profile id; runopenclaw models auth list —provider openaiafter repair before copying profile ids intoauth.orderor/model …@

`.

Flow shape (PKCE):

  1. generate PKCE verifier/challenge + random state
  2. open https://auth.openai.com/oauth/authorize?...
  3. try to capture callback on http://127.0.0.1:1455/auth/callback
  4. if callback can’t bind (or you’re remote/headless), paste the redirect URL/code
  5. exchange at https://auth.openai.com/oauth/token
  6. extract accountId from the access token and store { access, refresh, expires, accountId }

Wizard path is openclaw onboard → auth choice openai.

Profiles store an expires timestamp.

At runtime:

  • if expires is 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, refresh writes back to the main agent store instead of copying the refresh token into the secondary agent store
  • exception: some external CLI credentials stay externally managed; OpenClaw re-reads those CLI auth stores instead of spending copied refresh tokens. Codex CLI bootstrap is intentionally narrower: it can seed an empty openai:default or explicitly requested OpenAI profile only before OpenClaw owns OAuth for the provider. After that, OpenClaw-owned refreshes keep local profiles canonical and discovery does not add Codex CLI auth in any sibling slot. 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 don’t need to manage tokens manually.

Two patterns:

If you want “personal” and “work” to never interact, use isolated agents (separate sessions + credentials + workspace):

Terminal window
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

Section titled “2) Advanced: multiple profiles in one agent”

auth-profiles.json supports multiple profile IDs for the same provider.

Pick which profile is used:

  • globally via config ordering (auth.order)
  • per-session via `/model …@

`

Example (session override):

  • /model Opus@anthropic:work

How to see what profile IDs exist:

  • openclaw channels list --json (shows auth[])

Related docs: