openclaw - 💡(How to fix) Fix gateway 2026.5.12: oauth auth-profile (anthropic-cli) bypasses provider baseUrl, triggers "extra usage" classification [1 comments, 2 participants]

Summary

In gateway 2026.5.12, an auth-profile with type=oauth, provider=claude-cli (created by openclaw onboard --auth-choice anthropic-cli) appears to send requests directly to https://api.anthropic.com, ignoring the baseUrl configured under models.providers.anthropic.baseUrl in both openclaw.json and ~/.openclaw/agents/<id>/agent/models.json.

When the local environment also runs a Claude-Code-emulating billing proxy (e.g. zacdcook/openclaw-billing-proxy) on 127.0.0.1:18801 with baseUrl pointing at it, the proxy is not in the request path. Anthropic then classifies the raw OAuth call as a third-party app and routes it to the user's extra usage quota instead of their Max plan:

FailoverError: LLM request rejected: Third-party apps now draw from your extra
usage, not your plan limits. Add more at claude.ai/settings/usage and keep going.

After 5 such failures auth-state.json marks the profile disabledUntil with disabledReason: billing for a ~4 h cool-down.

claude -p ping from the same shell, with the same Claude CLI keychain, returns 200 against the user's normal Max plan — only the gateway path is affected.

Reproduction

1. Working OpenClaw 2026.5.12 install with openclaw onboard --non-interactive --auth-choice anthropic-cli ... (creates ~/.openclaw/agents/<id>/agent/auth-profiles.json with {type: oauth, provider: claude-cli}).
2. Run a local Claude-Code-emulating proxy on http://127.0.0.1:18801.
3. Set providers.anthropic.baseUrl = http://127.0.0.1:18801 in ~/.openclaw/agents/<id>/agent/models.json.
4. openclaw agent --agent <id> --message "hi"

Evidence the proxy is bypassed

~/.openclaw/logs/gateway.log just before the failure:

[agents/auth-profiles] read anthropic credentials from claude cli keychain
[ws] ⇄ res ✗ agent errorCode=UNAVAILABLE errorMessage=FailoverError: LLM request rejected: Third-party apps now draw from your extra usage, not your plan limits.

~/.openclaw/logs/billing-proxy.log — zero new entries in the time window; the proxy requestsServed counter stays at its previous value.

Expected

Either:

1. models.providers.<provider>.baseUrl is honored regardless of auth-profile.type (so oauth profiles flow through user-configured proxies), or
2. openclaw doctor / onboard documents that auth-choice anthropic-cli is incompatible with a custom baseUrl, and the field is treated as an error rather than silently ignored.

Workaround (verified working 2026-05-20)

1. Cherry-pick zacdcook/openclaw-billing-proxy#48 so the proxy adds the correct Claude-Code-emulation headers (mcp_ tool prefix, dynamic cch SHA256, model-aware betas).
2. Convert the profile in ~/.openclaw/agents/<id>/agent/auth-profiles.json to api-key mode:

   {"version": 1, "profiles": {
     "anthropic:claude-cli": {
       "type": "api_key",
       "provider": "anthropic",
       "key": "<the access token from the previous oauth profile>"
     }
   }}

3. Add an explicit provider block to openclaw.json (required for the api-key path to honor baseUrl):

   "models": {"providers": {"anthropic": {
     "baseUrl": "http://127.0.0.1:18801",
     "models": []
   }}}

4. Clear ~/.openclaw/agents/<id>/agent/auth-state.json to drop the billing cool-down.
5. Restart the gateway.

After this, openclaw agent requests show up in the proxy log as POST /v1/messages 200, the [STRIP] marker fires, and auth-state.json no longer accumulates failureCounts.billing.

Suggested fix

Make the baseUrl resolution in the oauth-profile code path mirror the api-key path. If there is an intentional reason oauth must hit api.anthropic.com directly (e.g. token-refresh flow uses claude.ai/v1/oauth/token which lives on a different host), expose it as an option (e.g. auth-profile.baseUrl or models.providers.anthropic.baseUrlOAuth) instead of silently ignoring the configured baseUrl.

Environment

• OpenClaw 2026.5.12 (commit f066dd2) on macOS 26.3, node v24.14.0
• Gateway running as a LaunchAgent, bind=lan, behind a Traefik reverse proxy
• Reproduced with billing proxy v2.2.3 + PR #48 fixes applied