diff --git a/docs/proxy/cli_sso.md b/docs/proxy/cli_sso.md
index 22b673e0f..b6e9f3afa 100644
--- a/docs/proxy/cli_sso.md
+++ b/docs/proxy/cli_sso.md
@@ -174,7 +174,7 @@ The classic `lite login` flow and virtual API keys keep working unchanged. `--pk
 
 ### The stored credential
 
-The key goes to your OS keychain, the same place `lite login` puts it, and the rest of the record goes to `~/.litellm/token.json` (mode `0600`). Next to the `base_url`, `user_id`, and `user_role` fields that `lite login` writes, a `--pkce` record also holds `expires_at`, `refresh_token`, `client_id`, `token_endpoint`, `revocation_endpoint`, `resource`, and `team_id`. The refresh token is in that file rather than in the keychain, so treat `~/.litellm/token.json` as sensitive on a `--pkce` login: anyone who can read it can exchange the refresh token for a working key
+The key and the refresh token both go to your OS keychain, the same place `lite login` puts the key, and the rest of the record goes to `~/.litellm/token.json` (mode `0600`). Next to the `base_url`, `user_id`, and `user_role` fields that `lite login` writes, a `--pkce` record also holds `expires_at`, `client_id`, `token_endpoint`, `revocation_endpoint`, `resource`, and `team_id`, none of which gets anyone a key on its own. On a machine with no usable keychain the key and the refresh token fall back into that same file and `lite login` says so; treat `~/.litellm/token.json` as sensitive whenever it does, because anyone who can read it can exchange the refresh token for a working key. A `--pkce` login made with an earlier `lite` leaves its refresh token in the file until the next `lite` command reads it and moves it into the keychain
 
 The key expires after `LITELLM_CLI_JWT_EXPIRATION_HOURS` (24 hours by default, see [JWT Token Expiration](#jwt-token-expiration)). You do not need to log in again when it does: the next `lite` command that needs the key renews it with the refresh token and saves the new pair. Each renewal rotates the refresh token, and a refresh token that was already used is refused
 
@@ -227,7 +227,7 @@ Requests made with the key are attributed to your user and the team you picked,
 lite logout
 ```
 
-`lite logout` sends the refresh token to the proxy's `POST /revoke` endpoint and then deletes `~/.litellm/token.json`. The refresh token is dead from that point on. The key itself is not revocable; it expires on its own within `LITELLM_CLI_JWT_EXPIRATION_HOURS`
+`lite logout` sends the refresh token to the proxy's `POST /revoke` endpoint and then clears both stores, the keychain entry and `~/.litellm/token.json`. The refresh token is dead from that point on. The key itself is not revocable; it expires on its own within `LITELLM_CLI_JWT_EXPIRATION_HOURS`
 
 Signing in again, with `lite login --pkce` or the classic `lite login`, does the same to the record it replaces: the new credential is saved first, then the previous login's refresh token is revoked, so an older copy of `token.json` cannot be renewed once you have signed in again. If the proxy cannot be reached for that revocation, the login still succeeds and says so
 
diff --git a/docs/proxy/management_cli.md b/docs/proxy/management_cli.md
index 21df97d79..3800cbea8 100644
--- a/docs/proxy/management_cli.md
+++ b/docs/proxy/management_cli.md
@@ -157,7 +157,7 @@ The credential is short-lived by design (default 24h, configurable via `LITELLM_
 
 A machine with no keychain, a headless Linux box for example, keeps the credential in that same owner-only file instead, and so do installs missing `keyring` and shells that set `LITELLM_CLI_DISABLE_KEYRING` to `1`, `true`, `yes`, or `on`, which turns keychain storage off entirely. `lite login` prints where the credential ended up either way. A credential written into `token.json` in plaintext by an older `lite` still authenticates: the next command that reads it moves it into the keychain and takes it out of the file
 
-A credential from `lite login --pkce` also comes with a refresh token: the CLI renews the key on its next use, `lite auth print-token` hands the current key to other tools, and `lite logout` revokes the refresh token on the proxy. Each renewed key goes to the keychain like the one before it, while the refresh token itself stays in `~/.litellm/token.json`. See [Browser sign-in with PKCE](./cli_sso#browser-sign-in-with-pkce)
+A credential from `lite login --pkce` also comes with a refresh token: the CLI renews the key on its next use, `lite auth print-token` hands the current key to other tools, and `lite logout` revokes the refresh token on the proxy. Each renewed key goes to the keychain like the one before it, and so does the refresh token that bought it. See [Browser sign-in with PKCE](./cli_sso#browser-sign-in-with-pkce)
 
 When you authenticate to a team during login, or want to move your stored key onto a different team afterward, use `lite teams assign-key` (see [Teams Management](#teams-management)). Inspect or clear the stored credential with: