Restoring a Wiped OAuth Token Set Without Losing Running Tasks

Restoring a wiped OAuth token set without losing running tasks requires sequencing credential recovery and task resumption. Save task state first, restore credentials without re-consent where possible, then reconnect the suspended tasks in a set order. New tokens restore access.

Why OAuth token loss hits running agents differently than interactive sessions

A browser session has a person nearby who can sign in again. An agent run may have nobody watching, several tasks partway through their work, and calls going to more than one provider. When credentials are lost, the process can keep running even though its API calls no longer work. In-flight work can stall or end in an uncertain state without the caller knowing why. The service is alive, but that does not mean it is doing its job.

A CRM update, a ticket that was created, or a message that was sent stays in place when the agent loses access. Restarting the run can repeat those actions. That makes credential loss a task-continuity problem as well as an access problem.

Token expiry and token loss also have different recovery paths. An expired access token can normally be replaced through a refresh token, but that path disappears when the refresh token is deleted or revoked. Causes include a vault failure, a user revoking access, an administrator removing the app, or a password change. Provider rules can also invalidate tokens, including Google's 6-month inactivity window and its separate per-client token cap. The cause matters because a local storage failure and provider-side revocation do not leave the same recovery options.

What is already lost and what is still recoverable before you touch credentials

Each running task must first be assessed for what it has completed and whether it can safely pause. Read-only or idempotent work can resume from a checkpoint without duplicating effects. Write tasks need closer attention because a pause can land between an external action and its confirmed response. A calendar entry may have been created even though the task never recorded success. If the missing response is taken to mean the action failed, the entry could be created again.

List the active tasks by their last confirmed checkpoint. Record the completed step, the external writes issued since then, and which writes can be reversed. For write-heavy agents, stable idempotency keys are a prerequisite for safe recovery because they let a repeated operation be recognized as a duplicate. Where a partial write exists, it must be resolved before the task restarts. The checkpoint describes what the agent knows, which may cover only part of what the external system did.

Durable checkpoints are recoverable after a process loss, while state held only in memory is not. The gap determines how far a task must rewind. LangGraph's PostgresSaver illustrates the storage principle by keeping every checkpoint as a versioned entry in PostgreSQL. It is one optional implementation. Whatever the checkpoint store, task state should contain credential references rather than raw tokens so recovery does not depend on restoring stale secrets inside each task.

Preserving task state before any credential operation

Freeze and record before touching authentication. Stop new tool calls and mark each affected task as suspended in durable storage at its last clean checkpoint. Record the last completed step and every pending tool call that has not received a confirmed response. Keep those tasks suspended while credentials are missing. Otherwise, a tool call can go out before all the credentials are back in place.

Save the task's logical state, including what it intended to do next and what it has confirmed doing. Store a connected_account_id or a secret manager ARN. On resume, the auth layer resolves that reference to a fresh credential. Putting tokens in checkpoints creates another place where secrets can leak and leaves task recovery tied to old token values.

Give pending writes an explicit unknown-state status when the call went out but no response came back. Do not settle that uncertainty by reading only the agent's local log. Before the task resumes, the provider's record must show whether the action happened. If access is needed to inspect that record, keep the write unresolved while credentials are restored. Securing state first preserves the question that recovery still has to answer.

Determining whether re-consent is required or whether silent re-authorization is possible

With tasks safely suspended, determine what was lost and where. Not every apparent wipe requires a consent screen, and expiry is not the same as revocation. For a user-delegated agent using authorization code with PKCE, the consent grant lives at the provider. The grant can still be in place after local tokens are deleted.

The first scenario is an expired access token with an intact refresh token. This calls for ordinary programmatic refresh. The auth layer exchanges the refresh token for a new access token without human action. There is no reason to send the user through consent simply because the access token has aged out.

In the second scenario, both tokens are lost from storage, but the provider-side grant is still valid. Silent re-authorization may work for an authorization code flow with PKCE if the provider supports that recovery path. The surviving grant is what makes this branch different from revocation. It is not a blanket guarantee that client credentials alone can replace a missing user-delegated token set. Establish whether silent recovery is available before treating this as a non-consent exchange.

The third scenario is a refresh token revoked at the provider. For that user-delegated grant, programmatic refresh cannot restore access, and a human must authorize again. Autonomous agents using client credentials flow follow a different model because the standard flow has no refresh token. They re-authenticate directly and can recover programmatically while their client secret or certificate remains intact.

Re-establishing credentials without triggering a consent screen

Once a supported non-consent path is found, run the exchange in the auth layer while tasks stay suspended. First acquire a distributed lock scoped to the connected_account_id and provider. Before the lock, several agent threads may be waiting for the same missing credentials. Under the lock, one exchange executes while waiting calls queue to reuse its result.

Next, complete the applicable refresh, silent re-authorization, or client credentials exchange. Store the resulting token set in the vault before signaling that tasks may resume. Until that write is complete, the restored credentials are not ready for task use. Tasks should keep only their credential reference. This keeps raw tokens out of task state, logs, and model context.

Provider rotation rules matter during this handoff. Google's documentation sets a limit of 100 refresh tokens per Google Account per OAuth 2.0 client ID, with a newly created token invalidating the oldest when the limit is reached. Microsoft's documentation states that Microsoft Entra replaces refresh tokens on every use but does not revoke the old token when it is redeemed. Store the replacement and securely delete the old token rather than assuming the provider has made it unusable. A successful exchange does not remove the need to manage the token set carefully.

Finally, restore proactive refresh before reconnecting tasks. Use per-account jitter so refresh attempts do not all arrive together. This separates routine expiry handling from incident recovery and reduces the chance of another synchronized credential gap. At this point, the token set is vaulted, its refresh schedule is active, and suspended tasks can begin reconnecting.

Reconnecting suspended tasks to the restored token set in the right order

Do not release every suspended task at once. A simultaneous release sends a burst of first calls to the provider, recreating the same rush caused by synchronized token expiry. Because tokens can have short lifetimes and providers have rate limits, that burst is a poor way to test whether recovery worked. Stagger resumption by priority and write risk instead. Start with read-only or idempotent tasks, whose calls can show that restored access works without the risk of doing the same thing twice.

Before write tasks resume, check the external system to find out what happened to their unknown-state operations. Query the provider's record and compare it with the checkpoint. If a partial write exists, handle the rollback or deduplication before repeating the step. Then resume write tasks in order of reversibility. An easily undone update should precede an irreversible action such as a sent message or an executed payment.

Each task should revalidate its credential reference on its first post-resume tool call. A token that was fresh when recovery began may no longer be fresh by the time the task is released. HubSpot's OAuth documentation gives an access-token lifetime of 30 minutes, which makes that delay relevant during staggered recovery. For each resume, log the task ID, its checkpoint, and the credential reference it resolved. That audit trail links external actions to the original or restored credentials and helps with later compliance work and finding out what went wrong.

When re-consent cannot be avoided and how to design for it without dropping tasks

Confirmed provider-side revocation ends the silent recovery path. Hold affected tasks in suspended state and send a re-authorization event to the relevant user or administrator. Once a new grant is established, resume from the saved checkpoint through the same controlled release process. Restarting the task over and over after provider-side revocation puts completed work at risk of being repeated.

This path needs durable checkpoints that survive the wait and a process restart. Re-consent may take minutes or hours, so memory alone is not enough. The system also needs a way to reach the person who can restore access, through email, Slack, or a dashboard alert. That notification should link directly to the consent flow.

A credential-reference model completes the handoff. When the new grant's tokens populate the credential slot, suspended tasks resolve the same reference without changes to their logical state. Recovery should also stay scoped to the affected provider. Tasks that depend only on other providers' valid credentials can resume while the revoked connection waits for consent.

Restarting from the beginning is simpler only for short, read-only tasks. For a long-running write task, it repeats every external write, and provider-side deduplication is not guaranteed to catch them all. Suspension preserves both completed work and unresolved operations.

Why recovery sequence reliability depends on the infrastructure layer, not just the agent logic

Freezing state needs a durable checkpoint store, and serializing the exchange needs a distributed lock. Restoring credentials needs a token vault with a programmatic API. Waiting for consent needs an event surface that can reach the right person.

Embedding tokens in environment variables, system prompts, or in-memory task state couples credential recovery to the process doing the work. The safer boundary is a separate auth layer that accepts a connected_account_id and resolves it to a fresh token. That layer handles proactive refresh, per-account jitter, and re-authorization events when it can no longer recover on its own. The task owns its progress and intended actions.

For products that serve many customers, keeping each user's credentials separate also limits how far an incident can spread. One customer's revoked grant should not contaminate another customer's vault or task state. Managed hosting that provides vaulting, refresh, locking, and isolation can move that infrastructure work out of agent code. The operator still needs task logic built around durable checkpoints and credential references. Reliable recovery comes from that separation, with task state preserved independently of whichever credentials currently make the next call possible.