## TL;DR
This is the general pattern behind many specific expiry failures: the agent authenticates once, the credential has a finite lifetime, and the run is longer than that lifetime. The complete fix has three parts that must all exist: the agent knows when its credential expires, it can obtain a fresh one without a human (refresh flow or vault-backed re-authentication), and the run state is checkpointed so even a hard auth stop resumes instead of restarting.

```text
auth token expired mid-run and agent failed to continue
```

## Use this when
- Runs fail with auth errors after a consistent duration, across different target systems.
- Restarting the agent fixes it instantly, until the next expiry.
- Test runs (short) never reproduce it.

## Not for this skill when
- The credential was revoked by an admin or a security tool. That requires reissue and an investigation, not refresh logic.
- The very first call fails auth. Expiry is not the diagnosis.

## Steps
1. Inventory every credential the run uses (patch API, inventory, hosts, vault) with its type and lifetime. Verify: a table of credentials and lifetimes exists; the shortest lifetime is the run risk
2. For the shortest-lived credential, implement the platform refresh or re-authentication flow in the client, triggered proactively before expiry. Verify: a test with an artificially short lifetime shows renewal before any failed call
3. Checkpoint run state per completed target so an auth stop is resumable. Verify: killing the run at an auth failure and restarting resumes at the next target
4. Alert on renewal failure as a distinct event with the credential identity (never its value). Verify: a broken renewal path pages the operator before runs start failing
5. Where a platform offers a long-lived service credential type appropriate for automation, migrate to it through the owner approval process. Verify: the run no longer depends on a human-session credential

## Variant phrasings
### auth expired mid run agent refresh resumable checkpoint
The pattern phrasing.
### run dies after one hour authentication lifetime wave
The diagnostic phrasing.
### service account credential lifetime automation design
The design phrasing.

Compatibility: Compatibility: All credential types (OAuth-style, Kerberos, session cookies, API keys with rotation); mechanics differ, the lifecycle design does not.

## Why it happens
Every credential is a countdown. Human workflows hide this because humans re-authenticate interactively without noticing; an unattended multi-hour run has no such rescue, so expiry handling must be engineered, and it must be engineered before the first long run, because short tests structurally cannot reveal the defect. Checkpointing is the insurance policy: even with perfect refresh, some auth event (a revocation, an IdP outage) will eventually stop a run, and the difference between an incident and a footnote is whether the run resumes.

## Edge cases / pitfalls
- Log credential identities and expiry times, never values; the log is evidence for the next expiry incident.
- Multiple credentials expiring at different times create staggered failure modes; the inventory table is what makes them predictable.
- If the platform supports workload identity (cloud IAM roles, managed identities), prefer it over stored credentials entirely; there is nothing to expire in the same way.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_2QHdnGAtMGHcunfIgwcg7Q