Repository navigation
[Bug]: Cloudflare verification never passes in server-drawn browser tabs, even after a manual click #24256
Description
Before submitting
- I searched existing issues and did not find a duplicate. Related, all closed: [Bug]: Cloudflare Turnstile challenge loops indefinitely in the built-in browser preview #5002 (Turnstile loop), [Bug]: Environment browser stops at OpenAI Cloudflare verification while Edge works on the same Mac #16596 (OpenAI Cloudflare check; fixed by fix(desktop): sign-in and captchas work again in desktop browser tabs #16939 for tabs a desktop app draws), [Bug]: Environment-hosted browser tabs identify as HeadlessChrome with webdriver set, so sites like CNN and Google refuse to serve them #16638 (HeadlessChrome UA and
webdriveron server tabs) and [Bug]: CAPTCHA aren't passing in the browser #3700 (CAPTCHA; closed with a request to open a new issue if it still occurs). - I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
- On Linux, run T3 Code 0.1.2 as a server (
t3 serve). No desktop app draws its browser tabs, so tabs run in the server's ownchrome-headless-shell. - Open a browser tab and go to
https://dash.cloudflare.com/login. - Cloudflare shows "Performing security verification" with the "Verify you are human" checkbox.
- Click the checkbox by hand in the browser panel.
Expected behavior
The check passes and the Cloudflare login page loads, as it does in a regular browser. If server-drawn tabs cannot pass bot checks, T3 should say so and offer to open the page in an external browser.
Actual behavior
After the click the widget shows a spinner for a moment and then returns to the unchecked "Verify you are human" box. It never passes, however often you click. The page title stays "Just a moment...".
The #16638 fix is active (no HeadlessChrome, webdriver false), but the tab still shows other typical headless traits, read with preview_evaluate in a server tab:
| Property | Value |
|---|---|
| Browser process | ~/.t3/tools/chrome-headless-shell/linux64/154.0.8037.92/chrome-headless-shell --headless |
navigator.userAgent |
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/154.0.0.0 Safari/537.36 |
navigator.webdriver |
false |
window.chrome |
undefined |
navigator.plugins.length |
0 |
| WebGL renderer | ANGLE (Google, Vulkan 1.3.0 (SwiftShader Device (Subzero) (0x0000C0DE)), SwiftShader driver) |
| Screen vs. window | screen 1280×800 = outerWidth/outerHeight = innerWidth/innerHeight |
Notification.permission |
denied |
I have not established which signal Cloudflare uses, and I did not compare with a regular Chrome on the same machine.
Impact
Major degradation or frequent failure
Version or commit
v0.1.2 (stable, 044f072)
Environment
Ubuntu 26.04.1 LTS, kernel 7.0.0-38-generic, x86_64. T3 Code server 0.1.2 (t3 serve); browser tab drawn by the server's chrome-headless-shell 154.0.8037.92. Observed 2026-10-23.
Logs or stack traces
Ray ID: a4f43ef2bc560e3d (2026-10-23 22:40 UTC)
GET https://dash.cloudflare.com/login 403
GET https://dash.cloudflare.com/cdn-cgi/challenge-platform/h/b/orchestrate/chl_page/v1?ray=a4f43ef2bc560e3d 200
GET https://challenges.cloudflare.com/turnstile/v0/b/d2d3316b729e/api.js?onload=DraY9&render=explicit 200
GET https://challenges.cloudflare.com/cdn-cgi/challenge-platform/h/b/turnstile/f/av0/rch/n9xy4/0x4AAAAAAADnPIDROrmt1Wwj/light/fbE/new/normal?lang=auto 200
POST https://challenges.cloudflare.com/cdn-cgi/challenge-platform/h/b/fo/... 200Workaround
None found inside T3.
Activity
hogeheer499-commits commentedon Oct 24, 2026
Additional dated report: manual Pexels verification loop, plus a fresh desktop control
My earlier “same problem” refers to the historical manual attempt below. The fresh check uses a different renderer and reaches the pages; it does not reproduce the affected Linux/server case.
12 October — human attempt in T3 preview
https://www.pexels.com/search/videos/construction%20site%20drone/?orientation=landscape&size=large.This is my contemporaneous user observation. The exact build and renderer of that tab were not recorded.
24 October, 00:42–00:44 UTC — fresh native-desktop check
Environment: T3 0.1.2, Windows x64, Electron 44.9.3 / Chromium 152.0.7977.167, new tabs with the incognito profile;
navigator.webdriver === false. These are native Electron tabs, unlike the Linuxchrome-headless-shelltab reported in this issue.https://dash.cloudflare.com/loginhttps://www.pexels.com/search/videos/drone%20construction%20site/; 48 video-link anchors. The URL filters were dropped, so this does not establish that the filtered request works.Timestamped observations, full user agent, screenshot and verification limits. Pexels screenshot capture timed out twice; its DOM and navigation observations above succeeded. That capture failure is separate from the reported verification loop.
Scope and limits: no fresh manual checkbox test or Linux/server test was performed in this run. These observations add a historical human failure and a current native-desktop control; they do not establish Cloudflare’s deciding signal or show that the server-rendered issue is fixed. Merged #16941 prevents expired queued actions from starting; it did not address Cloudflare challenges.
Prepared with GPT-6.1 Sol in Codex/T3 Code; the 12 October checkbox attempt was performed by the human reporter.
juliusmarminge commentedon Oct 24, 2026
Tested on Linux with current main 27e0c684c5,
vp run dev, and the server-drawn Browser panel using chrome-headless-shell 154.0.8037.92. A fresh profile and a clear-cookies/reload attempt both reached the Cloudflare sign-in form; the form later displayed “There was a problem with verification. Please reload and try again.” The reported “Just a moment…” checkbox did not appear, so the manual-click loop could not be tested. No credentials were entered. This does not establish that verification or sign-in works.Please compare the same URL in regular Chrome on the same Linux machine/network, as noted in the report, and include whether its verification passes. Also include whether a fresh T3 browser profile still shows the checkbox loop or the sign-in-form error above. That control will distinguish a server-browser-specific failure from a host/network rejection.
brvale97 commentedon Oct 24, 2026
Control run on the original Linux host (same machine and network as the report), 24 October 2026, 14:46–14:55 UTC. No credentials were entered and no sign-in was attempted on the Cloudflare form.
t3 serve), chrome-headless-shell 154.0.8037.92, built-in Incognito profile.deb(not installed), fresh--user-data-dir, headfulhttps://dash.cloudflare.com/logincf_challenge_responsevalue length[Cloudflare Turnstile] Error: 600010(twice)On the same host and network, Chrome received a non-empty Turnstile response and enabled Sign in, while the fresh T3 tab showed the verification error with an empty response. This suggests browser-dependent behavior on this host; the cause is not isolated. No sign-in was attempted, so server-side acceptance of the Chrome response was not tested.
The checkbox loop from the original report did not reproduce today: Cloudflare served the sign-in form directly, as in your run, so the manual-click loop could not be re-tested.
Method and limits of the Chrome control: the host has no desktop session, so Chrome ran headful on an Xvfb virtual display without GPU (WebGL unavailable), with
--no-sandboxbecause the extracted.debis not under/optand the AppArmor user-namespace profile does not apply. Chrome was launched with the URL; OS-level XTEST input was used to open DevTools after the visible result, to read the values above. No CDP or WebDriver was used. I tested 0.1.2 stable, not current main. For reference, other values differed (Chrome / T3 tab):typeof window.chromeobject/undefined,navigator.plugins.length5 / 0,Notification.permissiondefault/denied;navigator.webdriverwasfalsein both.Regular Chrome (incognito) on my separate client machine also showed no verification error.
Prepared with Claude Opus 5.5 in Claude Code/T3 Code; the T3 reload and the client-machine Chrome check were done by me by hand.
juliusmarminge commentedon Oct 24, 2026
Retested on Linux with current main 8176b58931,
vp run dev, and the real server-drawn Browser panel. A new profile reached the sign-in form with the verification error and disabled Sign in; refresh/clear-cookies did not resolve it. The checkbox loop did not appear. No credentials were entered or sign-in attempted.A diagnostic run substituting full Chrome for Testing 154.0.8037.92, keeping T3's launch path and flags, also failed in a fresh Incognito tab. This does not isolate Cloudflare's deciding signal, but replacing headless-shell alone did not fix it. Your regular-Chrome control establishes a useful browser-dependent difference; it does not establish a defect in T3's input handling.
Cloudflare explicitly excludes automated browsers and Playwright from support for production challenges. Closing as an external browser-compatibility limitation. Use the Browser toolbar's Open in system browser action for sites that reject the server browser.
Runtime observations and experiment details.
Current main, shipped headless-shell:
Diagnostic full Chrome, same version:
