aws sso login succeeds but every command still fails with ExpiredToken

The login worked, but stale AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY / AWS_SESSION_TOKEN environment variables are overriding your fresh SSO session. Run unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN, then retry. Env vars always beat the config file.

An error occurred (ExpiredToken) when calling the ListBuckets operation: The security token included in the request is expired

(The twist: you JUST ran aws sso login successfully and it still fails.)

Fix

1. Check for overriding env vars:

   env | grep AWS_

Expected culprits: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN set to old values.

1. Unset them (do not set them to empty strings):

   unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN

Expected: env | grep AWS_ no longer shows them.

1. Retry with the profile:

   aws sts get-caller-identity --profile your-profile

Expected: success, using the fresh SSO session.

1. Make it permanent: remove the exports from ~/.bashrc, ~/.zshrc, or your IDE's env config so new shells do not reintroduce the stale keys.

When this applies

• aws sso login completes successfully but commands immediately fail with ExpiredToken.
• aws configure list shows credentials coming from env rather than the profile.

When it does NOT apply

• The SSO session is genuinely expired (hours old): just aws sso login again.
• InvalidClientTokenId: the keys themselves are wrong, not merely stale.

Compatibility

• AWS CLI v1 and v2. The env-over-file precedence is the same in both.

Why it happens

The CLI's credential precedence is: env vars first, then config/credentials files, then SSO cache. aws sso login refreshes the cache, but if your shell exports old keys, the CLI never looks at the fresh session. This commonly comes from a .bashrc export added months ago for a different task.

Edge cases

• AWS_PROFILE set to an empty string is a separate trap (The config profile () could not be found); unset it too if present.
• Tools like direnv or IDE run configs can inject these vars invisibly; check those if env looks clean in your terminal but the error persists in the tool.