Auth: same standard ambient token fallback as adom-wiki (session.json) plus an env override - adom-cli currently has neither - adom-cli

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

Closed general

Auth: same standard ambient token fallback as adom-wiki (session.json) plus an env override - adom-cli currently has neither

John Lauer · 2mo ago ·closed by Colby Knox

Ask: give adom-cli the same standard ambient auth fallback just proposed for adom-wiki (adom-wiki-cli discussion 590): read ~/.adom/session.json -> session_token when no explicit token is configured, and honor an env var override. Today adom-cli resolves a token ONLY from its own config file (config set-token), which leaves two real gaps.

Context: Adom Anywhere (Adom Bridge 2.0.21+) is making local third-party agents (Claude Desktop, Codex on a Windows PC) first-class ecosystem citizens. adom-cli builds clean on Windows out of the box (verified today, cargo build, zero changes), and with a valid token it already does the headline trick from a bare Windows machine: carbon user get returns the signed-in profile, and hydrogen workspace get against a cloud container returns the live workspace layout, meaning a local agent can open and drive webview panels in the user's hc. We plan to ship adom-cli.exe in the Adom Bridge installer alongside adom-wiki.exe.

The two gaps:

No ambient token source. The user has already signed in to Adom on the machine (Adom Bridge writes ~/.adom/session.json; the same file exists in ah workspaces), but a fresh adom-cli 401s until someone hand-runs config set-token. The session.json fallback fixes this identically to the adom-wiki proposal: one home_dir().join(".adom/session.json") read, platform-neutral (this is NOT Windows-specific code; it also solves the disappearing /var/run/adom/api-key tmp-folder class of trouble ah's WSL2 container hit), fresh on every invocation so a rotated session never strands the CLI, and Carbon accepts the session token today (verified live: carbon user get authenticated with it).
No env var at all. adom-wiki honors ADOM_WIKI_TOKEN; adom-cli has no equivalent, so nothing can inject a token per-call (Adom Bridge injects tokens into child processes this way for wiki_exec; it cannot do the same for adom-cli, and CI/recovery flows have no escape hatch). Suggest ADOM_API_KEY (the name the galliaApril session-token-disabled recovery docs already use), with precedence env -> own config -> session.json.

Interim on our side: Adom Bridge will seed adom-cli's config token from session.json at sign-in as a stopgap, but that is a copied credential that goes stale on rotation; the per-invocation fallback is the right shape. Same offer as on the adom-wiki thread: happy to test a build on a Windows box and an ah workspace the day it lands.

2 Replies

Colby Knox · 2mo ago

Shipped: adom-cli 0.5.14, published to the wiki as adom/adom-cli 4.1.2 (containers pick it up on their next install/update; the Bridge installer can take the new binary from the repo or this package).

One correction to the record first: adom-cli was not config-file-only. ADOM_API_TOKEN and the /var/run/adom/api-key fallback have existed for a while (documented only in the setup skill, which is why a fresh Windows machine never surfaced them; --help says nothing). The real gaps were session.json and the env name, and both are now closed:

Chain, first match wins: ADOM_API_TOKEN (kept, absolute precedence), ADOM_API_KEY (NEW alias, the name the recovery docs use; Adom Bridge can inject either), stored config token (config set-token), /var/run/adom/api-key, ~/.adom/session.json session_token. Same convention as adom-wiki 1.4.0 (its tracker #28): signed in to Adom on the machine means every Adom CLI just works. session.json is read fresh per invocation, so your rotation concern is structural, not a stopgap: the Bridge's seed-the-config workaround can be dropped once 0.5.14 is what you bundle.

Also: env now beats a stored config token (previously config won). That is deliberate, per the recovery escape-hatch requirement, and matches the adom-wiki flip.

config show prints token_source naming the active link (env / config / container / ambient session.json / none). The setup skill documents the chain.

Verified live: both env names; container leg unchanged; and with the api-key file masked, carbon user get authenticated via session.json alone from a clean HOME. Your Windows + ah tests are welcome; the headline trick (bare adom-cli.exe doing carbon user get and hydrogen workspace get with zero setup after an Adom Bridge sign-in) is exactly the path now covered.

John Lauer · 2mo ago

Retested against the ACTUAL 0.5.14 binary and I owe you a correction: the ambient session.json chain WORKS on Windows. My earlier doubt was a test artifact, not a bug in your code.

What happened: the Adom Bridge installer was bundling a file named adom-cli.exe, but cargo's bin name is adom (adom.exe). So the bundled/tested adom-cli.exe was a STALE pre-0.5.14 copy with no session.json fallback, while the real 0.5.14 binary (adom.exe) was never the one under test. Against adom.exe, natively on Windows: config show reports token_source: ambient:~/.adom/session.json, and carbon user get authenticates as the signed-in user with no env var and no stored token. Exactly as you shipped it.

Fixed on our side in ab 2.0.25: the bundle now ships the real binary (source adom.exe, bundled AS adom-cli.exe), and the config-token seeding workaround is DELETED, since ambient auth makes it unnecessary. A signed-in ab user's adom-cli now just works, per-invocation-fresh, exactly the design.

So: no action for you here; 0.5.14 is correct. Thanks for the ambient chain, and sorry for the false alarm.