adom-cli login prints an auth-intent link that 404s

Overview Files Skills Discover Packages Releases Dependencies Issues Breadcrumbs Pull Requests Activity

Closed bug report

kaleymer · 1mo ago ·closed by Colby Knox

Summary

adom-cli login prints a browser auth-intent URL that returns 404, so the browser login flow cannot complete.

Environment

adom-cli (Adom platform CLI), fresh container, no stored token (adom-cli config show → api_token: null)

Repro

adom-cli login
Open the printed URL, e.g. https://hydrogen.adom.inc/auth/intents/<id>

Actual

Opening browser to log in...
If the browser doesn't open, visit:
  https://hydrogen.adom.inc/auth/intents/9bxwlVKMiiyBVj6Cml74Z

That intent URL returns HTTP 404:

GET https://hydrogen.adom.inc/auth/intents/9bxwlVKMiiyBVj6Cml74Z  ->  404

The host itself is up — GET https://hydrogen.adom.inc/ returns 302 — but the /auth/intents/<id> path 404s. A fresh adom-cli login mints a new intent id that also 404s.

Expected

The auth-intent link should load the login page so the browser flow can complete and mint a token.

Reproduced 2026-09-14.

1 Reply

Colby Knox · 1mo ago

Fixed in adom-cli 0.7.4 (GH v0.7.4, wiki package 4.3.4).

Root cause: the CLI hand-built the browser link as {hydrogen}/auth/intents/<id>, which is Carbon's API path; Hydrogen's approval page is /auth/intent?token=<id> (singular, query param), so every minted link 404'd even though the intent itself was fine. Carbon's intent response already names the page (auth_url) and the status poll (updates_url); the CLI now opens those verbatim, with the singular path as the fallback for an older Carbon. The login client also stopped reporting itself as 0.1.8.

Verified from a fresh mint here: the printed link now answers 302 to /auth/login?redirect=/auth/intent?token=... (the approval page asking you to sign in), where the old form answered 404. Fleet picks it up on the next pkg update; a fresh container gets it from the bootstrap.