Repository navigation
fix: web UI requests every scope, so Settings opens with an API key - #378
Merged
Merged
Conversation
The web UI exchanges an API key for a token with its own scope request,
a hand-written list that never gained settings:read / settings:write or
fleet:read. The daemon enforces the minted scopes verbatim, so a web
session signed in with a key could not open Settings ("Missing scope:
settings:read") or the fleet board, whatever the key allowed.
DEFAULT_WEB_SCOPES is now ALL_SCOPES_STRING, like the CLI's login set
(#303). login-scope-drift.test.ts now guards the web list too, and the
CLI comment names that test correctly.
Co-Authored-By: Claude Opus 5.5 (1M context) <[email protected]>
This was referenced Oct 11, 2026
rsharath
approved these changes
Oct 11, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What this fixes
Opening Settings in the web UI fails with
Missing scope: settings:readwhen you're signed in with an API key.The web UI asks ZeroID for a token using its own hand-written list of scopes. That list was never updated when the settings and fleet scopes were added. The daemon only allows what the token carries, so Settings and the fleet board were unreachable from the web UI, whatever the key itself allowed.
The web UI now asks for every scope codeoid defines, the same way
codeoid loginalready does (#303). The test that guards the CLI's list now guards the web list too, so it can't fall behind again.This alone may not clear the error for an existing key. ZeroID only grants scopes the key's identity allows. An identity created with an older scope list still caps the token, whatever codeoid asks for. On the machine where this was found, the identity was missing exactly
settings:read,settings:writeandfleet:read. That's a ZeroID setup issue, not a codeoid one; see the issue note below.Verification
login-scope-drift.test.tspasses (5 tests), as do the web auth tests (38). Typecheck and lint are clean for both the daemon and the web UI.For agents
web/src/lib/auth.ts:DEFAULT_WEB_SCOPES = ALL_SCOPES_STRING(imported from@highflame/codeoid-protocol, afile:dependency of the web UI).src/tests/login-scope-drift.test.tsadds a "web UI scope set" check against the source.src/cli.tsnow names that test correctly in its comment.zeroid/internal/service/oauth.goapiKeyGrant): requested ∩ key.scopes ∩ key policy ∩ identity policy ∩identity.allowed_scopes.tools:*and lackedsettings:*/fleet:read) caps every token.PATCH /identities/{id}with the fullallowed_scopes, or a new identity and key.codeoidaudience profile (embedded-UI sign-in,defaultAudienceScopeProfilesandallowedProfileScopes) also lackssettings:*,fleet:readandpipeline:*.🤖 Generated with Claude Code