agent loop detected: keeps adding the same KV binding, deploy fails validation every time

TL;DR: Stop editing wrangler.toml. The deploy fails validation because the KV namespace id in the config doesn't match anything in the target account, the binding name is duplicated, or the binding sits under the wrong environment section. List the real namespaces with wrangler kv:namespace list and compare before touching the file again. The loop continues because the agent edits the file without ever checking account-side state, so the error never changes.

agent loop detected: keeps adding the same KV binding, deploy fails validation every time

Steps

1. Freeze all config edits. Run wrangler kv:namespace list and capture the output. Expected: a list of namespaces, each with an id and title. If this command fails on auth, fix auth first - no config edit can help.
2. Compare the id from step 1 against the id in the kv_namespaces entry in wrangler.toml, character for character. Expected: exact match. A namespace created in a different account or a hand-typed id fails validation on every deploy.
3. Search wrangler.toml for the binding name and count occurrences. Expected: it appears exactly once across all binding types. The same name on a KV binding and an R2 or D1 binding is a validation error.
4. Check environment scoping. If you deploy with --env production, the binding must live under the matching [env.production] section. Expected: the binding is in the section for the environment you are actually deploying to.
5. Only now, make one targeted fix, then run wrangler deploy a single time and read the whole error. Expected: success, or a different error message. A changed error proves the loop is broken; an identical error means go back to step 2.
6. Add the loop guard to the agent: after two identical validation failures, it must run this checklist instead of editing the file a third time. Expected: the third identical edit never happens.

Use this when

• wrangler deploy rejects a KV binding and repeated wrangler.toml edits don't change the error
• the agent's diff shows the same kv_namespaces entry rewritten every pass
• the error says the namespace id doesn't exist or names a binding conflict
• bindings work locally but fail validation on deploy

Not for this skill when

• wrangler whoami fails - that's an auth problem, fix credentials first
• the error is a runtime "binding is not defined" in local dev - that's a dev-mode binding config issue
• the namespace genuinely doesn't exist yet - create it once with wrangler kv:namespace create and use the returned id verbatim
• the failure is a 429 rate limit - back off instead of editing config

Variant phrasings

• agent keeps rewriting wrangler.toml kv_namespaces and deploy still fails
• wrangler deploy KV binding validation failed on every attempt
• the KV namespace id is rejected even though it looks right
• duplicate binding name error after automated config edits

Why it happens

Wrangler validates bindings against the Cloudflare API at deploy time, not against your file. Editing the file can't fix a namespace id that doesn't exist in the account, a name collision, or wrong environment scoping. The agent loops because its only repair action is editing config, which never addresses account-side state, and it never diffs the error between passes, so it can't see that nothing changed.

Edge cases

• The namespace exists but in a different account. wrangler whoami reveals this; switch credentials or pin the account id for the run.
• ids copied by retyping get truncated. Copy the full id from the list output.
• Preview and production environments can use different namespace ids. Match the id to the environment you're deploying to.
• Two agents editing the same wrangler.toml concurrently clobber each other. Serialize config writes.

Provenance

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