agent loop detected: re-creating an already-existing secret on every failed run

TL;DR

Stop creating the secret; it already exists. Verify it once with wrangler secret list, then redirect the loop at the actual failure (usually the worker reading the wrong secret name, a missing binding, or an env mismatch). Re-putting an existing secret is a no-op that masks the real error and, worse, can overwrite a good value with a bad one.

agent loop detected: re-creating an already-existing secret on every failed run

1. Halt the loop and list the secrets on the worker once:

wrangler secret list

Expected: the secret name appears in the list. Existence is now established; no more put attempts without a reason.

1. Check what the worker code actually reads. Grep for the secret name as accessed at runtime (env.MY_SECRET) and compare against the name in the secret list, character for character.

Expected: the names match exactly. A near-miss (MY_SECRET vs MYSECRET, wrong env block) is the most common real bug hiding behind the loop.

1. Confirm the secret is set on the right environment. Secrets are per-env: a secret put without --env lands on the default env, while --env production reads only production secrets.

wrangler secret list --env production

Expected: the secret appears under the env the failing worker actually runs in. If it is missing there, this is the one legitimate case for a single put, with --env.

1. Read the actual error from the last failed run instead of the agent's summary of it. Look past "secret" mentions: is it a binding error, a 401 from a downstream API (meaning the secret VALUE is wrong, not missing), or a deploy validation error?

Expected: a diagnosis that is not "secret missing", because the secret is provably present.

1. Fix that real issue with one targeted change, and add a guard to the agent loop: before any future secret put, run secret list first and skip the put when the name exists.

Expected: the loop cannot recur; secret creation becomes conditional on absence.

Use this when

• wrangler secret put for the same name appears in every pass.
• secret list proves the secret exists.
• The failure persists unchanged across puts.

Not for this skill when

• The secret genuinely does not exist yet (first-time setup). One put is correct.
• You are rotating a compromised value. That is a deliberate overwrite, not a loop; say so in the run log.
• The secret exists but the value is wrong (downstream 401s). Update the value once with intent, then stop.

Variant phrasings

• agent keeps running wrangler secret put
• secret already exists loop
• autonomous agent recreating secrets every run
• wrangler secret put no-op retry

Why it happens

"Secret not found"-style errors make secret creation look like the fix, so the agent's repair policy fires wrangler secret put on every failure. But the error often means the code reads a different name, the wrong env, or the value is stale, none of which a re-put fixes. Each put succeeds silently (creating or overwriting), the next run fails identically, and the loop continues. The silent success of the put is what keeps the agent convinced it is making progress.

Edge cases

• A re-put with a wrong value is destructive: it replaces a working secret with a broken one, turning a config bug into an outage. Never put without verifying the value you are about to store.
• Bulk rotation scripts that put every secret unconditionally will trip this detector. Distinguish deliberate rotation (logged, one pass) from per-failure repetition.
• Preview environments have separate secrets. A secret present in production but missing in preview fails preview deploys; check the env, do not just re-put blindly.
• If the agent manages secrets from a vault, check the vault mapping first. The loop is sometimes "vault says set it, worker says missing" because the vault key maps to the wrong secret name.

Provenance

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