[whiskeylotus]

nullify auth login dead-ends on router tenants (AGI-6072). The CLI runs login on the tenant's own Cognito pool, whose GitHub callback is not on the router's shared App, so GitHub refuses the redirect. A router token also covers every org the user has, and with no org named, multi-org requests fail with ErrNoTenantID.

Login:

• Login at the auth host. Before signing in, the CLI asks the tenant GET /auth/cli/config where its login runs, then runs session, redeem and refresh there. A 404 means a stack that predates the endpoint, which keeps its own login. Any other failure, or an answer naming neither the tenant nor a known router (api.nullify.ai, api.router.dev.nullify.ai), fails closed.
• Credentials per auth host. Tokens are stored under the auth host. ~/.nullify/hosts.json binds each API host to its auth host. Old credential files keyed by the tenant keep working.
• Refresh keeps the org. Refresh no longer saves the server's default org (the lowest id) over the stored scope.
• No redirect replay. Auth calls do not follow redirects. Both client transports send the bearer only on an https request to their own API host that the caller made; redirect hops and other hosts go out without it.

Org picker:

• One org per command, never the lowest id. Commands run as the first of --org (name or id), NULLIFY_ORG, NULLIFY_GITHUB_OWNER_ID, the pick saved by nullify org use if the login still covers it, the git remote's owner if it names one org, or the only org. Otherwise a terminal prompts and remembers the answer, and anything else fails with the choices. The query_parameters old logins saved are never a pick.
• Org list. GET /admin/installations on the router (or a legacy tenant), kept to installations whose nullifyBaseUrl is this host. Orgs not routed yet and orgs on other hosts are reported apart. An API token names no org unless asked, so the server takes the token's own.
• MCP. nullify mcp serve starts on auth alone. Every tool takes an optional org argument, and list_organizations lists them. A call uses its argument, then serve --org, then the same chain, and returns the choices if still ambiguous. Resource reads follow the same rule. The scope rides in the request context, so concurrent calls for different orgs cannot cross.
• Visibility. auth status, auth config and whoami show the effective host, auth host and org. New nullify org list / nullify org use. README covers all of it.

flowchart LR
  CLI["nullify auth login --host acme"] -->|"GET /auth/cli/config"| T["api.acme.nullify.ai"]
  T -->|"auth_host=api.nullify.ai"| R["router: session, redeem, refresh"]
  T -->|"404 (older stack)"| S["tenant: session, redeem, refresh"]
  R --> C["credentials under the router; hosts.json: acme -> router"]

Loading

Companion auth side: https://github.com/Nullify-Platform/nullify/pull/17026.

Evidence:

• curl https://api.radiant.dev.nullify.ai/auth/cli/config and the dev router both answer 404 page not found today, the legacy path above.
• Not yet run against an environment: the plan's dev-radiant and legacy-stack checks are open before-merge items.

Pre-push review: independent four-reviewer pass plus judge on each wave.
CI: wave 1 checkpoint green at 97f81cb (https://github.com/Nullify-Platform/cli/actions/runs/40957439860).

plan: router-cli-login-public-cli

🤖 Generated with Claude Code