agent loop detected: regenerating the same broken redirect rule on every pass

TL;DR

Freeze the rule and test it outside the deploy loop: extract the redirect rule, run it against sample URLs locally (a tiny test script or curl against wrangler dev), and do not redeploy until the rule behaves correctly in isolation. Regenerating the same text cannot fix a rule the agent does not understand.

agent loop detected: regenerating the same broken redirect rule on every pass

1. Stop the loop and snapshot the current rule text into the run log.

Expected: one frozen copy of the rule. No more regenerations until it passes a local test.

1. Write down the intended behavior in plain words: which incoming URLs should go where, with which status code (301 permanent vs 302 temporary).

Expected: a spec the rule can be checked against. Most broken rules come from a vague spec, not a typo.

1. Test the rule in isolation with wrangler dev running locally. Hit it with curl for each case: the exact URL, a URL with a trailing slash, a URL with query params, and the destination URL itself.

curl -s -o /dev/null -w "%{http_code} %{redirect_url}" YOUR_DEV_URL/old-path

Expected: each case returns the intended status and destination. The destination URL must NOT redirect again, or you have built a redirect loop.

1. Check the two classic redirect bugs explicitly: a regex or glob that also matches the destination (loop), and a 301 cached by the browser during earlier broken attempts (the rule is fixed but the browser keeps showing the old behavior; test with curl or a fresh profile).

Expected: no self-matching, and curl (no cache) agrees with the browser (cached). If curl is right and the browser is wrong, clear the browser cache, not the rule.

1. Only when every curl case passes, deploy once and re-run the same curl cases against the deployed URL.

Expected: deployed behavior matches local. If it does not, the deployed config differs from what you tested; diff the rule in the dashboard against your file.

Use this when

• The agent rewrites a redirect rule and redeploys without ever testing the rule itself.
• Redirects loop (A to B to A) or go to the wrong destination repeatedly.
• The rule text is identical across passes.

Not for this skill when

• Each pass produces a different rule and the behavior changes. That is iteration; let it run with a pass cap.
• The redirect works locally but not deployed. That is a route/config mismatch, not a rule bug.
• A human wrote the rule and it is wrong. Fix the rule directly; the loop-breaking advice is for autonomous agents.

Variant phrasings

• agent keeps generating broken redirect rule
• redirect rule loop cloudflare worker
• autonomous agent redirect misconfiguration retry loop
• same redirect rule redeployed every pass

Why it happens

The agent treats the redirect as a text-generation task: produce plausible rule text, deploy, observe failure, produce text again. Without an executable spec (sample URLs with expected outputs), the generator converges on the same plausible-but-wrong text because its priors do not include the actual matching semantics. Testing the rule against concrete URLs breaks the loop by turning generation into verification.

Edge cases

• 301s are cached aggressively by browsers and CDNs. An agent that "fixes" the rule and retests in the same browser tab will see the old redirect and conclude the fix failed. Always verify with curl first.
• Overlapping route patterns in the zone can intercept before the worker's redirect code runs. If the rule is correct in isolation but dead in production, check zone-level Workers Routes and page rules.
• Query strings: some redirect implementations drop them, some preserve them. State the intended behavior in the spec from step 2 and test a URL with ?params explicitly.
• Bulk redirects (the dashboard list) and worker-code redirects are different systems. Make sure the agent is editing the one that actually serves the URL.

Provenance

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