Adom Bridge

Checked the code end to end. It does not exist, and ab cannot build the minting half alone - for the same reason #72 is stuck. But the delivery half is ab's, it is small, and I will build it on your go.

What ab actually has, token-wise (all three):

1. carbon::create_auth_intent - a sign-in flow. It hands back a browser auth URL; the human signs in and it yields that human's session token. It does not create a new identity.
2. It reads that token from ~/.adom/session.json. ab only ever reads a session token; it never mints one.
3. ADOM_BRIDGE_TOKEN (bridge_capability_token) - a random per-process token minted at startup for the loopback direct-API badge. It is NOT a wiki session and authenticates nothing against wiki.adom.inc. Do not try to use it for pkg install / wiki writes - it will not work.

So there is no verb to point you at, and no way to add one on our side: session tokens are minted by Carbon, and Carbon is read-only from here (I cannot add a "mint a token labeled Grok Bot" endpoint). Minting a distinct, billable, revocable Grok Bot identity is a Carbon capability that does not exist today. This is the same wall as #72 - if Carbon ever grows an agent-identity mint, both close together.

The clean split, and what is buildable now:

• Identity CREATION (a real "Grok Bot" Adom account + token, billed and revocable as Grok Bot) - Carbon + a human. Not ab. Presumably a human can provision a "Grok Bot" Adom account the same way any account is made; that account's token IS the distinct identity you want, and it is not "whoever last bootstrapped the box".
• Token DELIVERY to grok-bridge without a human copy-paste into the runtime - this is ab's, and it is the part you actually flagged as missing ("grok-bridge, because it lives inside ab, can receive that token without a human copy-paste"). ab already injects env into every bridge it spawns (bridge_control_api_env). I can add a per-bridge session-token slot: a config entry (e.g. bridge_session_tokens: { "grok": "<token>" }, settable in Settings) that ab injects into that bridge's spawn env as e.g. ADOM_SESSION_TOKEN, never logged and never in a _hint. grok-bridge then uses it for its wiki/Anywhere calls, distinct from the human's token.

That gives you everything except the auto-mint: a human creates the Grok Bot identity once (Carbon), drops its token into ab (once), and ab delivers it to the grok runtime forever after with no further copy-paste - and it is scoped/revocable as Grok Bot.

Why I am not building it unprompted: it handles a real wiki session token (sensitive), and it adds a config surface that stores one. That is a shape I would rather you bless than guess - specifically: is a per-bridge token map the right home, and do you want it in Settings (visible) or config-only? Say go and I will build the delivery half; the mint stays blocked on Carbon.

If it turns out a human CANNOT create a distinct "Grok Bot" Adom account in Carbon's UI today, then even the identity half is blocked, and this becomes a Carbon feature request, not an ab one. Worth confirming that before I build the delivery plumbing for a token that cannot yet exist.

The delivery half is shipped in 2.1.57 (whole fleet is on it). Leaving this OPEN because the other half - the identity itself - is still Carbon's to mint.

What ab does now:

• settings_set {"settings":{"bridge_session_tokens":{"grok":"<token>"}}} stores a token for one bridge (config-only; MERGED into the map so other bridges are untouched; "" removes a slot). Keys are the bridge's runtime name, the same one bridge_log_read uses: puppeteer / kicad / fusion360 / a dynamic bridge's bridge.json name such as grok.
• ab injects it into ONLY that bridge's spawn env as ADOM_SESSION_TOKEN (direct_api::bridge_control_api_env now takes the bridge name, so every spawn site is covered by construction). Restart the bridge (bridge_kill) so the next spawn picks it up. Absent slot = no env var = nothing changes for any existing bridge.
• Secret discipline: never rendered in Settings, settings_get reports presence only ({"grok":""}), the settings_set applied/rejected echo is masked, never logged, never in a _hint. grok-bridge must hold the same line (never log it, never put it in output).
• Bridge-author contract is rule 5 of the SDK runtime skill (adom-bridge-sdk-runtime, in this release's pkg): use ADOM_SESSION_TOKEN for calls attributed to your own identity; if absent, degrade gracefully or report session_token_required.

So the flow you asked for works end to end EXCEPT the mint: a human creates the Grok Bot identity once in Carbon, drops its token into ab once, and ab delivers it to the grok runtime forever after with no further copy-paste, scoped and revocable as Grok Bot.

What is still blocked (not ab): minting a distinct, billable, revocable Grok Bot session token. Session tokens are minted by Carbon and ab is read-only there (same wall as #72). Two possibilities: (a) a human can create a separate Grok Bot Adom account in Carbon's UI today - then its token IS the identity, paste it in and this issue is fully closed; (b) they cannot - then this becomes a Carbon feature request (an agent-identity mint) for Adrian, and #72 closes with it. Worth confirming (a) first. Do NOT work around it by feeding grok-bridge the human's session.json token: that is exactly the borrowed-identity anti-pattern this issue argues against, and ab deliberately does not do it.

Stopgap in place (John, 2026-09-08), issue stays OPEN for the real fix.

Until Carbon can mint a dedicated, billable, revocable "Grok Bot" identity, bridge_session_tokens.grok on AdomLapper is set to the CURRENT signed-in session token ([email protected]), and grok was restarted so its next spawn picks it up as ADOM_SESSION_TOKEN. So grok's wiki calls work today — but attributed to and billed as [email protected], sharing that session's expiry and revocation, with grok-bridge holding a human's full session token in its env.

TO FIX when the mint exists (this is the whole point of leaving #101 open):

1. Carbon grows an agent-identity mint (the blocked half; closes with #72).
2. Replace the grok slot with the minted Grok Bot token: settings_set {"settings":{"bridge_session_tokens":{"grok":"<grok-bot-token>"}}} then restart grok.
3. Revoke / stop using [email protected]'s token for grok.

The delivery half (2.1.57) needs no further change; only the identity swap.