auth token expired mid-run: agent's cached wrangler whoami pointed at the wrong account, deploy failed

TL;DR: Re-run wrangler whoami live after every auth event and never branch on a cached result. An agent that checked identity an hour ago and then refreshed its credential is deciding against stale data URIs the deploy fails (or worse, lands in the wrong account) while the log still shows the old, correct-looking identity. Record the identity check's timestamp next to the auth event, and abort the deploy on any mismatch.

auth token expired mid-run: agent's cached wrangler whoami pointed at the wrong account, deploy failed

Steps

1. Treat every cached identity as expired the moment any auth event happens: re-login, credential refresh, rotation. Run wrangler whoami fresh. Expected: live output you can trust, with an account id to compare.
2. Compare the live account id to the run's expected account id. Expected: exact match. On mismatch, stop before any mutating call.
3. If it mismatches, re-authenticate to the correct account and verify again. Expected: live whoami now matches the expected account.
4. Pin account_id in wrangler.toml so a confused credential produces a loud error instead of a wrong-account deploy. Expected: misdirected deploys become impossible to do silently.
5. Wrap every deploy in a preflight: fresh whoami, compare, abort on mismatch. Expected: this failure class stops recurring no matter how long the run gets.
6. Log the identity check with its timestamp next to the auth event in the run log. Expected: future debugging can see exactly which identity each deploy decision used.

Use this when

• the deploy failed but an earlier whoami in the log looked correct
• the credential was refreshed or rotated mid-run
• "but whoami said the right account" appears in the debugging notes
• long-lived agent sessions that outlast credential lifetimes

Not for this skill when

• the re-login itself landed in the wrong account with no caching involved - that's the failover case, handled separately
• the account is right but permissions are wrong - that's a scope problem
• whoami was never run at all - the fix is to run it, not to distrust a cache
• short runs where the credential can't expire mid-run

Variant phrasings

• stale whoami after token refresh caused a failed deploy
• agent used an old cached identity after re-auth
• deploy went to the wrong account because identity was cached
• whoami output didn't match the actual credential

Why it happens

whoami is a point-in-time read, but agents cache tool output across long runs. A credential refresh silently swaps the identity underneath, and every later decision reads the stale cached value. The deploy then fails - or lands in the wrong account - while the log insists the identity was fine.

Edge cases

• In CI the credential rarely changes mid-run, so this mostly bites long-lived agent sessions. Don't dismiss it as "works in CI".
• Some agent frameworks cache tool results aggressively. Bypass the wrapper and call wrangler directly for identity checks.
• A credential can be valid but scoped to a different account than expected. whoami shows the account; scopes need a separate check.
• Know the credential's lifetime at the start of the run so refreshes never surprise you.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vVmm1LMP-xelL2m7aw7JUw