[Bug]: Remote environment pairing cannot complete behind Cloudflare Access OAuth

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/web

Steps to reproduce

1. Run a T3 Code server on an HTTPS backend host protected by Cloudflare Access using an OAuth identity provider.
2. Create a normal T3 Code pairing credential for that backend.
3. From the hosted/static T3 Code web client, try to pair the remote environment by entering the backend host plus pairing code, or by opening a hosted pairing URL that points at that backend host.
4. Complete the Cloudflare Access OAuth login if prompted, then retry pairing.

Expected behavior

Remote environment pairing should support an OAuth/browser-login gate in front of the backend. A user should be able to authenticate with Cloudflare Access, then complete T3 Code's own pairing/token exchange and connect the WebSocket without bypassing Access for the backend.

Actual behavior

Pairing cannot complete when Cloudflare Access protects the backend host.

Observed behavior from an Access-protected HTTPS backend:

GET /.well-known/t3/environment
# Returns a redirect to https://<team>.cloudflareaccess.com/cdn-cgi/access/login/...
# Includes: www-authenticate: Cloudflare-Access

OPTIONS /api/auth/websocket-ticket
# Returns 403 from Cloudflare Access for the preflight request

Current T3 Code remote pairing expects direct browser access to the backend descriptor and token endpoints. The client fetches /.well-known/t3/environment, exchanges the pairing code at /oauth/token, then requests /api/auth/websocket-ticket with Authorization: Bearer .... There does not appear to be a connection mode for a Cloudflare Access/browser-cookie OAuth gate, and the Authorization request triggers a CORS preflight that Cloudflare Access blocks by default unless OPTIONS is handled specially.

Related but not duplicate issues found during search:

• #227: broad first-class remote-access planning; mentions Cloudflare Tunnel, but not Cloudflare Access OAuth/cookie-gated pairing.
• #1928: closed CORS issue for fetching the remote auth endpoint; not specifically an Access challenge/OAuth flow or credentialed browser-cookie connection model.
• #3054: WebSocket reconnect churn behind imperfect links/proxies; not the initial pairing/authentication failure.

Impact

Blocks work completely

Version or commit

main @ 32e784483

Environment

• Hosted/static T3 Code web client pairing with a remote HTTPS backend
• Backend behind Cloudflare Access with OAuth identity provider login
• Browser-origin pairing flow, not a same-origin deployment

Logs or stack traces

The browser never reaches T3 Code's environment descriptor/token flow unauthenticated because Cloudflare Access intercepts the descriptor request first.

The later WebSocket-ticket request shape uses Authorization: Bearer, which causes a CORS preflight. Cloudflare Access rejects OPTIONS by default unless the Access app or edge config handles preflight separately.

Screenshots, recordings, or supporting files

No response

Workaround

Bypass Cloudflare Access for the T3 Code backend or expose it through a different trusted tunnel/auth path. Configuring Cloudflare Access CORS/OPTIONS handling may avoid the preflight rejection, but it does not provide a first-class T3 Code pairing flow that can launch OAuth, persist the Access/browser-cookie mode, and retry the descriptor/token exchange with credentials.

Start by tracing the browser pairing flow through /.well-known/t3/environment, /oauth/token, and /api/auth/websocket-ticket, including the WebSocket connection and the observed OPTIONS preflight. Done means a hosted client can authenticate through the browser-login gate, complete T3 Code's pairing exchange, and connect without bypassing the protected backend.