docs(cli): move the lite login credential to the OS keychain - #960
Conversation
`lite login` now stores the credential in the OS keychain and keeps only non-secret metadata in ~/.litellm/token.json, falling back to that owner-only file when no keychain is available. Update the CLI, SSO, and identity provisioning pages, and document LITELLM_CLI_DISABLE_KEYRING. See BerriAI/litellm#37566
|
bugbot run |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 718a28a. Configure here.
The quick start offered litellm[proxy] as an equivalent way to get the lite command, so a reader who took that path never reached a keychain and nothing told them why. Also names the SDK getter, which needs keyring for the same reason and returns None without it even when lite login stored a credential.
|
bugbot run |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit da1a807. Configure here.
# Conflicts: # docs/proxy/management_cli.md
|
bugbot run |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 8a02047. Configure here.
TLDR
lite loginnow puts the credential in the OS keychain instead of writing it into~/.litellm/token.json, so the pages that told readers their credential sits in a plaintext file were wrong. See BerriAI/litellm#37566What changed in the code
The credential goes into the OS keychain (macOS Keychain, Windows Credential Manager, Linux Secret Service) under the service
litellm-cliand the accountcredential.~/.litellm/token.jsonkeeps only non-secret metadata: base URL, user id, email, role, auth header name, and the sign-in timestamp, in a0600file inside a0700directory. With no keychain reachable, which covers a headless Linux box, an install without the optionalkeyringpackage (it ships with thecliextra), andLITELLM_CLI_DISABLE_KEYRINGset to1/true/yes/on, the credential falls back into that same owner-only file, andlite loginprints which store it used.lite logoutclears both and warns when the keychain will not release the entry. A plaintext credential left by an olderlitestill authenticates, then moves itself into the keychainPages changed
docs/proxy/identity_provisioning.md: Step 4 saidlite loginstores the token at~/.litellm/token.json, and the paragraph after it said LiteLLM has no OS keychain integration at all. Both now describe keychain storage, the metadata-only token file, thekeyringrequirement, and the fallback. The support matrix rows for on-device storage and keychain storage were flipped to matchdocs/proxy/management_cli.md: thelite logincredential section only said the token was "stored". It now says where each half lives, what the fallback cases are, whatLITELLM_CLI_DISABLE_KEYRINGdoes, and whatlite logoutclears. The quick start offeredlitellm[proxy]as another way to get thelitecommand without saying that extra leaves outkeyring, so that line now names the consequence, and the credential section says the SDK getterlitellm.get_litellm_gateway_api_key()needskeyringfor the same reasondocs/proxy/cli_sso.md: the login step now points at where the credential lands and links to the section above, and its install step carries the samelitellm[proxy]correctiondocs/proxy/config_settings.md: addedLITELLM_CLI_DISABLE_KEYRINGto the environment variable tableChecks
npm run buildpasses. The broken-anchor warnings it prints are all pre-existing links from release notes intodocs/proxy/loggingand friends; none of them touch these pagesNote
Low Risk
Documentation-only updates to CLI credential storage. No runtime, auth, or proxy behavior changes in this PR.
Overview
Aligns CLI docs with keychain storage for
lite login: the session key lives in the OS keychain (servicelitellm-cli), and~/.litellm/token.jsonkeeps non-secret metadata. Fallback remains the owner-only file when there is no keychain,keyringis missing (litellm[proxy]does not include it), orLITELLM_CLI_DISABLE_KEYRINGis set.PKCE still puts the refresh token in
token.json(treat that file as sensitive).lite logoutclears both stores and warns if the keychain entry cannot be removed. Older plaintext tokens migrate into the keychain on next read.Also documents
LITELLM_CLI_DISABLE_KEYRINGin the env-var table and flips the identity-provisioning support matrix from “no keychain” to “yes”.Reviewed by Cursor Bugbot for commit 8a02047. Bugbot is set up for automated code reviews on this repo. Configure here.