Token-only auth by default, with opt-in interactive_login()

[ggprior]

Problem

The CLI's interactive login collected an email and password and posted them to /auth/login/ as an OAuth2 password grant. Under OIDC the credential lives at the identity provider, so SSO users have no password to type and that path cannot succeed for them.

Two things made it worse:

• Browser login was attempted first, but every failure fell through to the password menu.
• The callback wait had no timeout and no fallback, so a dropped callback hung the client until Ctrl+C. The login URL was never printed, and webbrowser.open returns True on many headless boxes.

Default path: token only, never interactive

This is a library, so authentication is not allowed to block on input. init() resolves a token from, in order:

1. a token set via set_access_token()
2. TABPFN_TOKEN, read from os.environ at resolution time
3. a token cached by an earlier interactive_login()

If none resolve it raises, pointing at https://ux.priorlabs.ai/account/api-keys and mentioning interactive_login(). It never prompts, even on a TTY. A token that was supplied but rejected gets a distinct message rather than "not found".

TABPFN_TOKEN is now read from os.environ at resolution time rather than snapshotted at import, so setting it after import tabpfn_client takes effect.

Incidental credential-leak fix

set_token() conflated "use this token" with "remember this token", and was called on every init(). So an env-supplied TABPFN_TOKEN was silently copied into site-packages/tabpfn_client/.tabpfn/config. It is now split:

• set_token() — in-process only
• persist_token() — writes the cache, called only by interactive_login()

A token the caller supplies stays in memory. The cache holds only the result of an explicit login.

Opt-in path: interactive_login()

from tabpfn_client import interactive_login
interactive_login()

Never reached from init(), fit(), or predict() — asserted by test_init_never_triggers_interactive_login. It offers:

• Log in — opens the login page (SSO included) and waits for the API key. Adapted from the browser-auth flow in the TabPFN package: the callback server runs in a daemon thread while the main thread polls stdin, so the callback and a manual paste race each other. If an identity provider drops the callback, the user pastes a key and the flow still completes. Headless sessions get the URL plus an OSC 52 clipboard copy, bounded by a timeout.
• Create an account — runs entirely in the terminal. This is what course providers like DLAI need: students creating accounts from a notebook, where a browser tab is not viable.

CLI password login stays removed, since that is what OIDC broke.

Signup flow, reshaped per OPC-26

Six steps to three (OPC-26):

Before	After
Step 1 Terms & Conditions (interactive y/n)	Notice under the email field
Step 2 Account Details	Step 1/3 Account details
Step 3 Create Password	↳ merged
Step 4 Data Privacy (interactive y/n)	Notice under the email field
Step 5 Your Information	Step 2/3 Complete your profile
Step 6 Help Us Serve You Better	↳ merged
—	Step 3/3 Verify your email

Also: the role list is replaced with the agreed nine (Data Scientist, ML Engineer, AI Engineer, Software Engineer, Product Manager, Researcher, Student, Executive, Other), and "What do you want to use TabPFN for?" is dropped.

The notice prints before the email prompt rather than after, so it is on screen before anything is submitted. It also carries the "do not upload personal, confidential or sensitive data" clause, because the server still requires agreed_personally_identifiable_information — this way we are not asserting an agreement the user never saw (OPC-26 open question 3).

One deliberate deviation

The email opt-in is reworded as requested, but ships unchecked (y/N) rather than pre-checked.

The new wording is marketing ("product news, offers and resources"), not support. Consent for that must be a clear affirmative act under GDPR Art. 4(11) / Recital 32, and CJEU Planet49 (C-673/17) held that a pre-ticked box is not valid consent. Prior Labs GmbH is established in Germany, so this applies directly. Flipping the default is a one-line change if whoever owns consent policy signs off — tracked in OPC-26.

Verification

Against live api.priorlabs.ai / ux.priorlabs.ai:

• Real TTY, no token: init() raises immediately with the api-keys message and does not wait for input. A non-TTY test cannot catch this regression, so it was checked through a pty.
• Env token: TABPFN_TOKEN=<bogus> leaves no file on disk.
• Browser path (pty, webbrowser.open stubbed): simulated GUI redirect delivered the token, callback won the race, paste prompt exited cleanly.
• Callback server: success page redirects to /redirect-success; a callback without a token deliberately does not set the event, so the paste prompt keeps running.
• Signup (pty, mocked server): full three-step flow completes; payload carries the new role, no use_case, both consent flags, and contact_via_email=False on a bare Enter.
• Live /auth/password_policy/ returns ["Length(8)", "Uppercase(1)", "Numbers(1)", "Special(1)"] and the restored client parses it correctly.

171 unit tests pass; ruff and basedpyright clean.

Not verified: no real account was created against production, so the signup path is covered end-to-end against the mock server only. Say the word if you want a live run with a throwaway address. Separately, whether a real OIDC round-trip preserves the callback param is unconfirmed — if it is dropped, the paste fallback covers it, which is why the race matters.

🤖 Generated with Claude Code

[ggprior]

Follow-up: interactive signup flow

Feedback on the signup steps (role list, redundant steps, email opt-in wording) is tracked separately in OPC-26 — Rework interactive signup flow in tabpfn-client.

It is deliberately out of scope for this PR, which is about where authentication happens, not what the signup form asks. OPC-26 carries three open questions that need answers before anyone implements — notably whether a CLI-native signup should exist at all now that registration happens in the browser.