Cloudflare's Turnstile Spin has coding agents wire Siteverify into the backend

A widget-only install shows visitors a challenge while the server accepts every request, valid token or not ^[2]. What to do with the Siteverify result is up to the application. Cloudflare's own example is holding a login until the visitor passes ^[15].

Cloudflare has seen enough of that gap to build a repair path. It says the recovery flow pre-empts "the kind of support tickets people used to send about their Turnstile setups" ^[13]. In plainer words, step two got skipped often enough to generate tickets. The install base behind those tickets is large. Turnstile processes about three billion verifications on a typical weekday ^[3]. More than 23,000 accounts created a new widget in one recent week ^[4], about 3,300 a day ^[1]. Cloudflare wrote that demand "reaches far beyond people who write backend code every day" ^[5].

The design is sound on the points I care about. Spin does not send application code to Cloudflare or ask Cloudflare to change it remotely ^[9]. The team's own agent, whether Claude Code, Cursor, Codex or another, makes the approved edits ^[9]. The only new object in the Cloudflare account is the widget ^[10]. Validation stays in the backend, next to the logic that decides what happens after a challenge ^[10]. That puts the pass-or-fail branch in code the team already reviews and deploys. Spin starts from the dashboard, from Wrangler, or from a public skill URL pasted into an agent ^[7].

The weak spot is the detection signal. Cloudflare monitors Siteverify calls for each widget ^[11]. A call count proves tokens reached the API, but not that the handler acted on the answer. A handler that calls Siteverify, logs a failure and carries on would count as validated. So would a widget shared by two forms where only one backend route checks tokens. Cloudflare's post does not describe how Spin's generated code handles a failed or unreachable Siteverify response.

When an agent's Turnstile diff comes up for review, I trace one protected request through it in order:

1. The server reads the token from the incoming form or API request. 2. It POSTs the token to Siteverify before the protected action runs. 3. A fail result, a missing token or a Siteverify error ends the request with a rejection.

Step three is a choice. Failing closed when Siteverify is unreachable locks out real users during an outage. On a login or signup form, where the widget exists to stop automated abuse, I would still fail closed.

Migrations need the same trace. Spin detects the old CAPTCHA provider's markers and proposes a substitution plan before applying it ^[14]. If the old provider's server check survives, it should reject Turnstile tokens, and the breakage shows on the first submit. If that check is deleted and no Siteverify call replaces it, the form keeps working and the token goes unchecked.