fix: derive the login scope set from ALL_SCOPES instead of hand-listing it

[saucam]

The bug

codeoid login asked ZeroID to mint a hand-maintained literal scope list (src/cli.ts) that had drifted from ALL_SCOPES in both directions:

Never minted — real scopes the daemon enforces:

settings:read   settings:write   fleet:read
pipeline:create  pipeline:read  pipeline:answer  pipeline:manage

Not real scopes — requested but never defined in SCOPES:

tools:read  tools:write  tools:execute  tools:agent

codeoid enforces token scopes verbatim — auth.ts: scopes: (identity.scopes ?? []) as Scope[], with no server-side expansion or default. So a scope missing from the mint request is unreachable for the life of the key. A login token structurally could not open the settings screen, the fleet board, or any pipeline verb.

Why it was hard to diagnose

The failure surfaces far from its cause — a bare Missing scope: settings:read from a daemon whose config is otherwise fine. Nothing an operator can do fixes it:

• re-login — mints the same deficient set
• restarting the daemon — irrelevant; the scope is fixed at mint time
• upgrading ZeroID — ZeroID never sees these as anything but opaque strings. Verified on a live instance: credential_policies.allowed_scopes and service_keys.scopes were both empty (no ceiling), oauth_tokens had zero rows (stateless JWTs, nothing cached), and no codeoid scope string appears in the ZeroID binary at all. It grants what it's asked for — it was simply never asked.

The comment above the list read "The full scope set codeoid asks ZeroID to mint", which is precisely the claim that rotted when settings:* was added in fc149bd (2026-07-16).

The fix

const CODEOID_LOGIN_SCOPES = ALL_SCOPES_STRING;

ALL_SCOPES is the single source of truth. ALL_SCOPES_STRING is the same join terminal/client.ts and tui/ws.ts already use — only the login path hand-rolled its own.

Owner-tier question, flagged not buried

This makes the login token owner-tier: it now includes settings:write and pipeline:manage, which scopes.ts explicitly calls out as owner-tier ("the same trust class as settings:write").

I think that's right for the single-operator daemon codeoid targets — the key is minted by, and for, whoever runs it, and delegated access is already expressed by exchanging this token down (the conductor and watcher paths do exactly that) rather than by under-minting here. But it is a deliberate widening and worth a second opinion. The alternative is a named OWNER_SCOPES constant that's still derived, just narrower.

Verification

lint + typecheck clean, 2372 pass / 0 fail. Four new drift assertions: the derivation is checked structurally (so re-introducing a literal array fails), plus no-missing, no-unknown, and an explicit check on the seven scopes whose absence caused the original report.

After merge, one codeoid login <key> re-mint is needed for existing keys.

🤖 Generated with Claude Code