auth token expired mid-run: agent deployed to production instead of preview after re-login

TL;DR

The agent's token died mid-run. It re-authenticated, but the new session lost the --env preview context, so the next deploy went to production with untested code. Roll back production, pin the environment in every deploy command the agent runs, and make re-auth restore the full session context (env, account, working directory).

The query

auth token expired mid-run: agent deployed to production instead of preview after re-login

Use this when

• A token expired mid-run and the subsequent deploy hit the wrong environment.
• Production changed unexpectedly during what should have been preview work.
• The agent's session spans re-authentication.

Not for

• Token rotation as routine hygiene (no incident).
• Deploys that fail ON expired auth (nothing was deployed wrongly).
• Wrong-environment deploys with no auth event (config problem).

Steps

Step 1: Assess and roll back production

npx wrangler deployments list --name [worker-name]
npx wrangler rollback [previous-production-version-id] --name [worker-name]

Expected result: production serves the last known-good version. Do this before any forensics.

Step 2: Reconstruct what the agent did

Read the run log around the re-login: which commands ran, with which flags, against which environment.

Expected result: the exact command that deployed to production without --env preview. The missing flag is the mechanism.

Step 3: Pin the environment in every deploy invocation

Never rely on session context for the environment. Every deploy command names it explicitly.

npx wrangler deploy --env preview

Expected result: re-authentication cannot change the target, because the target is in the command, not the session.

Step 4: Make re-auth restore full context

The agent's re-login flow must re-establish account, environment, and working directory, then verify with whoami and a dry run before any mutating command.

Expected result: post-re-auth sessions are verified identical to pre-expiry sessions before work resumes.

Step 5: Add a production-deploy guardrail

Require explicit confirmation (or a separate, narrower credential) for production deploys. Preview deploys stay frictionless.

Expected result: even a confused agent cannot deploy to production by accident. The blast radius of session confusion is preview-only.

Why it happens

Session state is implicit: the agent 'knows' it is working in preview because of earlier commands. Re-authentication resets the implicit state while the agent's plan still assumes it. The deploy command without --env falls back to the default environment, which is production. Implicit context plus a session reset equals a wrong-environment deploy.

Edge cases

• The same failure mode hits account context: re-login to the wrong account deploys to the wrong account's worker.
• Token expiry during a multi-step run can also strand half-applied changes (secrets rotated, code not deployed). Audit the full run, not just the deploy.
• Short-lived tokens expire more often; the re-auth flow must be robust, not rare.
• Consider separate tokens for preview and production with different scopes, so a preview token cannot deploy to production at all.

Provenance

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