openclaw - 💡(How to fix) Fix Auth event log: append-only structured logging for auth decisions [1 comments, 1 participants]

Problem

OpenClaw's auth system has no historical logging. When an auth lane fails and the system falls back to another lane, the only trace is a single lastFailureAt timestamp in auth-profiles.json that gets overwritten on each failure. There's no append log, no fallback event trail, and no way to reconstruct auth behavior over time.

What happened

We downgraded a Claude subscription from $200 to $100. The OAuth token was invalidated but the system silently fell back to a secondary auth lane. We had no notification, no log trail, and no way to know how long the primary lane had been dead. When specialists started failing intermittently, we couldn't correlate those failures to auth lane issues because there was no connection between FailoverError: LLM request timed out and the underlying auth state.

Diagnosing required manually parsing JSON timestamps from auth-profiles.json - archaeology, not observability.

Impact

• Silent auth lane degradation went undetected for ~24 hours
• Specialist failures couldn't be attributed to auth vs capacity vs bugs
• No way to retrospectively audit auth health over a time range
• Operators can't answer: "when did lane X start failing and what happened?"

Proposed Solution

1. Append-only auth event log

A structured, timestamped log file (auth-events.jsonl or similar) that captures every auth-relevant event:

{"ts":"2026-04-01T15:31:00Z","event":"auth_failure","profile":"anthropic:oauth-mc","reason":"auth_permanent","model":"claude-opus-4-6","session":"agent:main:main"}
{"ts":"2026-04-01T15:31:00Z","event":"lane_fallback","from":"anthropic:oauth-mc","to":"anthropic:oauth-bc","reason":"auth_permanent"}
{"ts":"2026-04-01T15:31:00Z","event":"lane_disabled","profile":"anthropic:oauth-mc","reason":"auth_permanent","until":"2026-04-01T20:31:00Z"}
{"ts":"2026-04-01T17:36:00Z","event":"lane_restored","profile":"anthropic:oauth-mc","method":"manual_token_update"}

2. Lane switch events

When the system falls back from one auth lane to another, log it as a discrete event with the reason. Not silent fallback.

3. Error context on LLM requests

When an LLM request fails, the error should include which auth lane was attempted and why it failed - not just the generic timeout/failure. This lets operators correlate specialist failures to auth issues.

4. CLI query support (nice-to-have)

openclaw auth log                    # recent auth events
openclaw auth log --profile oauth-mc # filter by lane
openclaw auth log --failures         # failures only
openclaw auth log --since 24h        # time range

Context

• Current auth state storage: ~/.openclaw/agents/{agent}/agent/auth-profiles.json → usageStats
• Only stores: lastUsed, errorCount, lastFailureAt, failureCounts, cooldownUntil, disabledUntil, disabledReason
• No historical data - each field is overwritten, not appended
• Auth fallback decisions happen in the gateway request lifecycle