# 2026-06-10 — Final answer on the auth errors (the real cause)

## What was actually happening
- Gateway was auto-updating from 2026.6.1 → 2026.6.5 between 16:51 and 17:26 UTC
- Each version transition triggered a graceful restart (SIGTERM → drain → restart)
- Restarts happened at: 16:51, 17:18, 17:23, 17:26
- Console log proof: "I've seen things you wouldn't believe. Anyway, I'm updated." at 17:21:55
- This is a CLI-driven update cycle, not a cron job, not a watchdog, not me

## Why "Provider authentication failed" kept appearing
- Each restart created a new process with new in-memory auth state
- Session DB had records pointing to old (now-dead) processes
- When new message arrived, OpenClaw sometimes picked an old session, tried to resume it, failed
- The error message is generic — OpenClaw's failure-handler says "auth failed" when really it means "session is stale, can't resume"
- This is a misleading error message, not an actual auth issue

## What I got wrong (chronicle of bad diagnoses)
1. First: "stale error, system healthy" — partially right but lazy
2. Then: "Paperclip DataAnalyst on bad model" — there WAS a paperclip issue but unrelated to chat
3. Then: "memory embedding provider was openai without key" — true latent issue, but not the cause of THESE errors
4. Then: "gateway is bouncing every 4-5 min" — right about bouncing, wrong about why
5. Then: "openclaw service-mode watchdog" — wrong, it was the update cycle
6. Finally (now): the actual cause was a background update I'd noted at 16:54 but failed to connect to the symptoms

## Verified stable at 17:38 UTC
- OpenClaw 2026.6.5 (5181e4f) installed
- Gateway PID 396060, uptime 12m50s, parent = systemd user (1036)
- Model: ollama/minimax-m3:cloud, 2s direct response
- This message is reaching Larry → pipeline works

## Lessons (DO BETTER NEXT TIME)
1. **When you see a pattern of errors right after a config change or update, check if an update is in progress first.** I noted "v2026.6.5 available" at 16:54 and forgot about it.
2. **"Provider authentication failed" is a generic error.** Don't take it at face value. Check session IDs and process PIDs to see if it's really an auth issue or a session resume failure.
3. **Stop diagnosing from inside the broken system.** I kept running config.set and trying to fix things while the gateway was actively updating — every fix attempt could have been a wasted effort.
4. **Larry's signal: he said "still same error" FIVE times. That means the fix I just claimed didn't work. I should have believed him immediately and looked harder.**
5. **The user usually knows.** "Hermes VPS was not down, not you" was Larry telling me "the error is coming from you." I read it backwards.