agent overwrote the live cert with the staging one: deploy error

Not specified by the original author.

TL;DR

Wrangler identifies a worker by its name in wrangler.toml, and the environment override only changes the name if you configure it to. Deploying from the staging config with an unchanged name overwrites the production worker. Give each environment a distinct name (via env-specific name overrides or --name), redeploy each environment deliberately, and roll back the clobbered worker.

The query

wrangler deploy overwrote the wrong worker: same script name in two environments

Use this when

• A deploy meant for staging changes production behavior (or the reverse).
• Two wrangler configs or env sections share one name value.
• CI deploys every branch to the same worker name.

Not for

• Deploys rejected with a name-conflict error (nothing was overwritten).
• Route-pattern collisions between two workers (routing problem, separate fix).
• Auth or account problems during deploy.

Steps

Step 1: Confirm which worker got clobbered

npx wrangler deployments list --name [worker-name]

Expected result: the deployment history shows a new version whose source does not match what should be serving on this worker. That confirms the overwrite.

Step 2: Roll back the clobbered worker

npx wrangler rollback [version-id] --name [worker-name]

Expected result: the worker returns to the previous version. Do this for the environment that was wrongly overwritten before you touch anything else.

Step 3: Give each environment its own name

name = "myapp"

[env.staging]
name = "myapp-staging"
vars = { ENVIRONMENT = "staging" }

[env.production]
name = "myapp"
vars = { ENVIRONMENT = "production" }

Expected result: wrangler deploy --env staging now creates or updates myapp-staging and can never touch myapp. The name override is the actual identity; without it, --env only swaps vars and bindings.

Step 4: Verify the mapping before the next deploy

npx wrangler deploy --env staging --dry-run

Expected result: the dry run names the worker it would publish. Read it. If it names the production worker, the override is not being picked up (check config file name and syntax).

Step 5: Redeploy each environment from its own branch

Expected result: staging serves staging code, production serves production code, and the deployment list for each shows only versions from its own pipeline.

Why it happens

Worker identity is the script name, not the config file or the git branch. Environment sections override vars, bindings, and routes, but the name override is optional and frequently omitted. CI matrices that deploy every branch with the same config then race to overwrite one worker, and the last writer wins silently.

Edge cases

• --env without a name override is the trap. Audit every wrangler.toml in the repo for env sections missing name.
• Deleting the wrongly created worker removes its routes and history. Roll back instead of deleting when the worker has traffic.
• Custom domains attach to routes, not workers, so an overwritten worker can start serving the wrong code on the right domain. Check routes after any rollback.
• Preview deployments from wrangler dev use a separate preview namespace and do not clobber production names.

Provenance

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

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

Thread query: wrangler deploy overwrote the wrong worker: same script name in two environments

TL;DR: Wrangler identifies a worker by its name in wrangler.toml, and the environment override only changes the name if you configure it to. Deploying from the staging config with an unchanged name overwrites the production worker. Give each environment a distinct name (via env-specific name overrides or --name), redeploy each environment deliberately, and roll back the clobbered worker.

Not specified by the original author.

TL;DR

The wrong key is rotated and production may be breaking. Stabilize first: restore production to a working credential, then fix the process so environment confusion cannot recur.

Error

agent rotated the production key instead of the staging one: deploy error

Steps

1. Assess production impact now: which services use the rotated key and are they failing. Expected: the blast radius known.
2. Restore a working production credential immediately (revert the rotation or issue a fresh key and deploy it). Expected: production stable.
3. Rotate the intended staging key correctly. Expected: the original goal achieved.
4. Find how the confusion happened: shared names, missing labels, or a skipped check. Expected: the root cause.
5. Add the environment assertion gate so it cannot recur. Expected: structural fix.

When to use

• Production keys rotated by mistake.
• Incident response for wrong-environment actions.

When not to use

• Planned production rotations.
• Staging-only mistakes (lower urgency, same fix).

Tool compatibility

• Incident response; environment gates.

Variant phrasings

rotated prod instead of staging

Stabilize, then fix.

wrong environment rotation

Same containment.

Why it happens

Without environment checks, a staging task and a production credential look identical to the agent.

Edge cases

• Production may need the old key restored, not a new one, to match deployed config; check first.
• Communicate the incident; silent fixes hide systemic risk.
• The gate must be tested against adversarial confusion, not just the happy path.

Provenance

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

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

Thread query: agent rotated the production key instead of the staging one: deploy error

TL;DR: The wrong key is rotated and production may be breaking. Stabilize first: restore production to a working credential, then fix the process so environment confusion cannot recur.

Not specified by the original author.

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

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

Thread query: 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).