fix(auth): stop the unwired browser-PKCE provider from stalling login

[abrichr]

The bug

openadapt-desktop login on macOS or Windows opens a browser tab and then blocks for 180 seconds before falling back to token paste.

available_providers() puts BrowserPkceProvider first on every interactive desktop, and its is_available() returned True on macOS/Windows regardless of configuration. _exchange_code is the first step that needs a Supabase project, but it runs after the loopback wait — so the failure is discovered only once the full timeout (default 180.0) has elapsed.

Reproduced against origin/main on macOS with no configuration:

origin/main is_available() on this desktop: True
login() raised after 3.0s: Timed out waiting for the browser login to complete.   # timeout=3.0 for the demo; the default is 180.0
browser tabs opened: 1
URL opened: https://app.openadapt.ai/login?redirect_to=http%3A%2F%2F127.0.0.1%3A58201%2Fcallback&code_challenge=...

Why it can never succeed

The provider is not wired end to end, and every missing piece is hosted-side:

Step	Blocker
Browser redirects to loopback	GET /login reads only checkout_session_id and next. It ignores redirect_to, code_challenge, code_challenge_method, state.
Supabase accepts the redirect	The uri_allow_list is rewritten on every production deploy and holds no loopback entry.
Mint an ingest token	POST /api/ingest-tokens authenticates the browser session cookie and requires name. It answers 401 to this provider's Authorization: Bearer <supabase access token>, and the provider sends label, not name.

Verified live against app.openadapt.ai: the four query parameters land in the Next.js RSC searchParams payload and are never consumed by the page.

OPENADAPT_SUPABASE_URL / OPENADAPT_SUPABASE_ANON_KEY are referenced nowhere except this module — not in openadapt-cloud, openadapt-flow, openadapt-tray, or any CI configuration. The provider has never been able to complete anywhere.

The change

Make is_available() require the Supabase configuration up front. It is a necessary condition the provider already depends on, so it now reports unavailable instead of costing the operator a silent multi-minute stall, and PasteTokenProvider — which works — runs immediately.

Deliberately minimal:

• Nothing is removed. The provider and the chain order are unchanged.
• Reversible. Configuring the environment and the hosted contract restores the flow.
• Client-side only. No hosted or deployment change; nothing here touches production.

Tests

test_full_flow previously passed only because it stubs both _exchange_code and _mint_ingest_token — precisely the two halves the server does not implement. It now runs against a configured provider, so it still covers the wired path.

New regression tests cover the unconfigured case, partial configuration (URL without key and key without URL), and the user-visible symptom — that no stray browser tab is opened.

478 passed in tests/test_engine/, ruff clean. The one unrelated failure locally is test_presentation_export needing openadapt_types, which is not installed in this environment and is untouched by this change.

Note on direction

The shipped path to a credential remains the one-time pairing flow in engine/auth/pairing.py (oap_ secret → /api/local-bridge/pairings/{claim,confirm,abort}), which the hosted control plane does implement. This PR does not propose reviving browser-PKCE; it stops an unwired provider from degrading the login path that works. Reviving it is a hosted-contract decision.

🤖 Generated with Claude Code

https://claude.ai/code/session_01NyCHrzA1psrKMFfroYbzaM