auth login: allow user-scoped API key without --oid#289
Merged
maximelb merged 1 commit intoMay 7, 2026
Merged
Conversation
The validator currently rejects `auth login --uid X --api-key Y` with "Error: --oid and --api-key are required for API key login.", even though `--uid` is documented as the flag for user-scoped API keys. This makes brand-new accounts un-bootstrappable from the CLI because they have no organization yet — chicken-and-egg, since the user can't list/create their first org without working CLI auth, but can't auth without an OID, but doesn't have an OID until they create an org. The User API Key itself is a fully valid credential — env-var auth (LC_UID + LC_API_KEY) works for `auth list-orgs` already, which is the only call needed to bootstrap from "I have a User API Key" to "I know my OIDs". The bug was purely in the `auth login` validator forcing an --oid constraint that the rest of the CLI doesn't need. Fix: rework the validator to accept either: --oid + --api-key (org-scoped key — existing behavior) --uid + --api-key (user-scoped key — new path, --oid optional) When neither --oid nor --uid is provided, emit a clear error distinguishing the two key types. The `write_credentials` call already handles oid=None correctly (skips writing the field), so no downstream changes needed. Tested: - `auth login --uid X --api-key Y` (no --oid) → succeeds - `auth list-orgs` against those credentials → returns the user's orgs - `auth login --api-key Y` (neither --oid nor --uid) → clear error - `auth login --oid X --api-key Y` (existing org-scoped path) → unchanged - `auth login --oauth --provider google` → unchanged
maximelb
approved these changes
May 7, 2026
3 tasks
maximelb
added a commit
that referenced
this pull request
May 7, 2026
Follow-up to #289. When a user re-runs `auth login --uid X --api-key Y` in an environment that previously held an `--oid + --api-key` login, the old `oid` survived in config because `write_credentials` only writes fields it is given. Subsequent commands would silently pair the new user-scoped credentials with the stale org context. Fix it by dropping the `oid` field from the affected env block right after the write whenever the login was user-scoped (`uid` set, `oid` unset). Mirrors the post-write cleanup pattern already used by the OAuth flow for `api_key`. Also refresh the `--ai-help` text so it advertises the user-scoped shape (`--uid + --api-key`, no `--oid`) that #289 enabled, and add unit tests for the validator branches and the stale-oid cleanup -- neither was covered before. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
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
2 participants
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.
Problem
limacharlie auth login --uid X --api-key Y(a user-scoped API key, no org context) is rejected with:…even though
--uidis documented as the flag for "user-scoped API keys" and the--ai-helptext says "If you are using a user-scoped API key, also pass --uid."This breaks the bootstrap flow for any brand-new LimaCharlie account that hasn't created an org yet — chicken-and-egg, since the user can't list/create their first org without working CLI auth, can't auth without an OID, and doesn't have an OID until they create an org.
The User API Key itself is fully capable of user-scoped operations —
LC_UID + LC_API_KEYenv vars already work forauth list-orgs(the only call needed to bootstrap from "I have a User API Key" to "I know my OIDs"). The bug was purely in theauth loginvalidator forcing an--oidconstraint that the rest of the CLI doesn't actually need.Discovered
Live during a workshop where one student chose the email/password signup path (which yields a User API Key). The OAuth-via-Google/Microsoft paths worked fine; the email/password path failed at this validator.
Fix
Rework the validator to accept either of two valid shapes:
--oid + --api-key— org-scoped key (existing behavior, plus optional--uidfor service accounts)--uid + --api-key— user-scoped key,--oidoptionalWhen neither
--oidnor--uidis provided, emit a clear error distinguishing the two key types so users picking the wrong key from the LC web UI get pointed to the right one.The
write_credentialscall already handlesoid=Nonecorrectly (skips writing the field), so no downstream changes are needed.Tests run locally against a real account
auth login --uid X --api-key Y(no--oid)auth list-orgsagainst those credentialsauth login --api-key Y(neither--oidnor--uid)auth login --oid X --api-key Y(existing org-scoped path)auth login --oauth --provider googleDownstream impact
A workshop's
setup.shcurrently uses a placeholder-OID workaround (--oid 00000000-0000-0000-0000-000000000000 --uid X --api-key Y) to bootstrap users with brand-new accounts. After this lands and ships, that workaround becomes unnecessary — but it'll keep working since the--oid + --api-key + --uidshape stays valid.