Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After upgrading from v2026.3.24 to v2026.3.28, Anthropic auth fails with HTTP 401 "OAuth authentication is currently not supported" for setups using a type: "token" auth profile with a sops SecretRef (tokenRef). The root cause is a breaking change in 3.28's credential classification logic: mode: "token" is now routed as "oauth" instead of being preserved as its own category, causing the gateway to send Authorization: Bearer instead of x-api-key.

Steps to reproduce

1. Configure an Anthropic auth profile using type: "token" with a sops SecretRef:

{ "auth": { "profiles": { "anthropic:my-profile": { "provider": "anthropic", "type": "token", "tokenRef": { "id": "anthropic_token", "source": "sops" } } } } }

1. Upgrade from v2026.3.24 → v2026.3.28
2. Send any message — auth fails with HTTP 401

Expected behavior

type: "token" profiles should continue to work as they did on v2026.3.24. The resolved credential should be sent as x-api-key (API key routing), not Authorization: Bearer (OAuth routing).

Actual behavior

HTTP 401 from Anthropic API: "OAuth authentication is currently not supported"

Root cause (verified against source)

3.24 behavior (pi-embedded-BaSvmUpW.js):

mode: mode === "oauth" ? "oauth" : mode === "token" ? "token" : "api-key"

type: "token" profiles resolve to mode: "token" — a distinct category, routed as API key.

3.28 behavior (auth-profiles-B5ypC5S-.js):

if (entry.mode === "api_key") return "api_key"; if (entry.mode === "oauth" || entry.mode === "token") return "oauth"; // ← breaking change

type: "token" profiles are now classified as "oauth" and routed with Authorization: Bearer, which Anthropic rejects with 401 unless the token is a true OAuth access token.

Additionally — a secondary check in isAnthropicOAuthApiKey() detects the sk-ant-oat prefix in the resolved token value and further reinforces OAuth routing, making config-level workarounds (e.g. changing mode to "api_key") ineffective — the token prefix check fires regardless of profile config.

OpenClaw version

2026.3.28 (regression from 2026.3.24)

Operating system

Ubuntu 24.04 LTS (Linux 6.18.7 x64)

Install method

npm global

Model

anthropic/claude-opus-4-6 (primary) / anthropic/claude-sonnet-4-6 (fallback)

Provider / routing chain

openclaw → anthropic (direct, sops SecretRef)

Additional provider/model setup details

Auth setup

OAuth token (Claude Max subscription) stored via sops/age encryption, resolved at runtime via SecretRef. Token has sk-ant-oat prefix. Profile configured as type: "token" (not type: "oauth").

Logs, screenshots, and evidence

2026-03-30T11:55:47.952-07:00 [agent/embedded] embedded run agent end: runId=boot-... isError=true model=claude-opus-4-6 provider=anthropic error=HTTP 401 authentication_error: OAuth authentication is currently not supported. rawError=401 {"type":"error","error":{"type":"authentication_error","message":"OAuth authentication is currently not supported."},"request_id":"sha256:9c4a9fdae5b9"}

2026-03-30T11:55:49.467-07:00 [model-fallback/decision] model fallback decision: decision=candidate_failed requested=anthropic/claude-opus-4-6 candidate=anthropic/claude-opus-4-6 reason=auth next=anthropic/claude-sonnet-4-6

2026-03-30T11:57:05.074-07:00 [agent/embedded] embedded run agent end: runId=... isError=true model=claude-opus-4-6 provider=anthropic error=HTTP 401 authentication_error: OAuth authentication is currently not supported. rawError=401 {"type":"error","error":{"type":"authentication_error","message":"OAuth authentication is currently not supported."},"request_id":"sha256:b543065bb2db"}

Additional context from 3.24 logs (current version):

[agent/embedded] ignoring context1m for OAuth token auth on anthropic/claude-sonnet-4-6

This confirms that even on 3.24, isAnthropicOAuthApiKey() classifies the token as OAuth via prefix detection — but 3.24 still routes the request correctly as API key. In 3.28, the new entry.mode === "token" → "oauth" classification makes this fatal.

Impact and severity

High / Blocking — Any setup using type: "token" with sops SecretRef auth cannot upgrade to 3.28. All API calls fail with 401. No config-level workaround available due to the secondary isAnthropicOAuthApiKey() prefix check overriding explicit profile classification.

Additional information

Suggested fix

Either:

1. Restore the 3.24 behavior — preserve "token" as a distinct mode that routes as API key, not OAuth
2. Add a new type: "api_key" migration path for setups that use type: "token" with non-OAuth tokens, with a openclaw doctor --fix migration
3. Make isAnthropicOAuthApiKey() check the profile mode field rather than (or in addition to) the raw token prefix, so explicit mode: "api_key" config can override prefix detection