Problem
codecarbon/cli/auth.py currently treats any requests.RequestException while validating the local access token as a successful validation path:
_validate_access_token() returns True if the discovery document or JWKS fetch fails due to a network error.
get_access_token() then reuses the stored access token and lets the API perform the final decision.
This is intentional for offline / flaky-network support, but it is worth documenting because it creates a clear caveat: when the auth server cannot be reached, the CLI does not locally prove that the token is still valid. A stale token, a provider migration, or a revoked token may still be accepted by the CLI until the API rejects the request.
Why this matters
The behavior is easy to misread as local token validation. In practice, the CLI is using a best-effort check and then deferring trust to the server. That is acceptable for availability, but it should be called out explicitly so users and maintainers understand that:
- the CLI may proceed while offline without proving token freshness;
- failure to reach the auth server is not equivalent to token valid;
- security-sensitive changes in the auth flow should preserve this distinction.
Suggested follow-up
- Document the fallback behavior in the CLI auth code and/or user-facing docs.
- Consider logging a warning when the CLI skips local validation because the auth server is unreachable.
- If stricter behavior is ever desired, add a separate mode for must validate locally versus best-effort offline fallback.
Reference
Observed while reviewing PR #1199, which migrates JOSE validation from Authlib to Joserfc without changing this fallback path.
Problem
codecarbon/cli/auth.pycurrently treats anyrequests.RequestExceptionwhile validating the local access token as a successful validation path:_validate_access_token()returnsTrueif the discovery document or JWKS fetch fails due to a network error.get_access_token()then reuses the stored access token and lets the API perform the final decision.This is intentional for offline / flaky-network support, but it is worth documenting because it creates a clear caveat: when the auth server cannot be reached, the CLI does not locally prove that the token is still valid. A stale token, a provider migration, or a revoked token may still be accepted by the CLI until the API rejects the request.
Why this matters
The behavior is easy to misread as local token validation. In practice, the CLI is using a best-effort check and then deferring trust to the server. That is acceptable for availability, but it should be called out explicitly so users and maintainers understand that:
Suggested follow-up
Reference
Observed while reviewing PR #1199, which migrates JOSE validation from Authlib to Joserfc without changing this fallback path.