# A signed-in browser hitting the OAuth login page gets no flow from Kratos

Found while writing m16's e2e (`scripts/auth-oauth21-e2e.sh`), out of m16's diff so filed rather than fixed.

Every Hydra authorization re-runs the login redirect — Kratos accepts each login challenge without asking Hydra to remember the login, so the browser lands on `/auth/login?login_challenge=…` even when it already holds a live Kratos session. In that state, `GET {kratos}/self-service/login/browser?login_challenge=…&return_to=…` with `Accept: application/json` (exactly the call `use-ory-flow.ts` makes) answers **`200` with a body of `null`** — no `ui.nodes`, no `redirect_browser_to`, no `Location`. Observed against Kratos v1.3.1 + Hydra v2.2.0 in the e2e harness.

`use-ory-flow.ts` expects Kratos to _throw_ `browser_location_change_required` here (line ~221, "OAuth2 short-circuit: an existing session satisfied the login challenge") — and [ADR012 §7](../../docs/ADR012-auth.md) documents that as the behavior — so a `null` flow likely leaves the login page on its skeleton, or falls through to the challenge-less redirect bootstrap (line ~295), abandoning the authorization. That would mean **an already-signed-in user connecting an agent dead-ends**, which is the most common path in `docs/ADR025-connect-an-agent.md`'s recipe.

Not yet confirmed in a real browser (the sandboxed Playwright browser can't reach the e2e stack's localhost ports) — **verify first**: connect an agent while signed into the dashboard and watch what the login page does. If it reproduces, the fix is in the login page/hook (handle a null/empty flow with a `login_challenge` by navigating the browser to Kratos's HTML endpoint, which _does_ 303 to Hydra's continue URL), not in the consent route.

m16's own e2e sidesteps it by driving each authorization from a fresh cookie jar (a clean browser), which is why all 12 legs pass.

Source: `w4/m16` t004, 2026-07-12.
