Turnstile + Privy Cross-Origin Pitfall

Problem

ATXP Chat / accounts.atxp.ai uses Privy for authentication. Privy loads in a cross-origin iframe from auth.privy.io. Inside this iframe, Cloudflare Turnstile (sitekey 0x4AAAAAAAM8ceq5KhP1uJBt) protects the email submission form.

Why 2captcha token injection fails

2captcha solves Turnstile correctly (task accepted, token returned in ~6 seconds)
The token must be injected into the Privy iframe's DOM — not the parent page
browser_console runs JavaScript in the parent page context, which cannot access cross-origin iframe content (same-origin policy)
Creating <input name="cf-turnstile-response"> in the parent page has no effect — Privy ignores it
Calling window.turnstile.render() or callbacks on the parent window object doesn't reach Privy's sandbox

What was tried (all failed)

document.querySelector('[name="cf-turnstile-response"]') in parent — not found
Creating hidden input with token — ignored
Calling window.cf_turnstile_callback(token) — undefined
Direct Privy API POST to auth.privy.io/api/v1/authentication/email/send-code — 404
Direct ATXP auth endpoint — 405/404

Working alternatives

DuckDuckGo browser + VPN — real browser with privacy mode bypasses all detection (user confirmed 13+ accounts registered this way)
Residential proxies — might work if browser fingerprint is clean enough
Manual registration — user opens atxp.chat in real browser, enters email, solves Turnstile manually, gets magic link

Key takeaway

Cross-origin iframe Turnstile (Privy pattern) is a hard blocker for headless browser automation. No amount of JavaScript injection from the parent context can bypass it. The token must be delivered inside the iframe's JavaScript sandbox, which requires either:

CDP-level injection into the iframe context (complex, browser-engine-specific)
Real browser with user interaction
Finding an API endpoint that doesn't go through Privy's front-end Turnstile

2.0 KiB Raw Permalink Blame History