infisical: unauthorized" api error
Fixes the Infisical CLI or API returning 'unauthorized': refresh the token and check its scope. Use when infisical commands fail auth. Not for secret-value issues.
TL;DR
Unauthorized means the token is missing, expired, or scoped away from the project. Re-authenticate, confirm the token covers the project and environment, and retry.
Error
"infisical: unauthorized" api errorSteps
- Check whether a token is configured for the CLI at all. Expected: you see whether auth state exists.
- Re-authenticate to get a fresh token. Expected: login succeeds.
- Verify the token's project and environment scope includes what you are accessing. Expected: scope matches.
- If using a service token, confirm it has not been revoked or rotated. Expected: the token is live.
- Retry the failing command. Expected: authorized.
When to use
- Infisical CLI or API calls return 401/unauthorized.
- After token rotation or project changes.
When not to use
- 403 on a specific secret (finer-grained permission).
- Wrong secret values (data, not auth).
Tool compatibility
- Infisical CLI and API; user and service tokens.
Variant phrasings
infisical 401 unauthorized
Same handling.
infisical token expired
Re-authenticate.
Why it happens
Tokens expire, get revoked on rotation, or are scoped to a different project or environment than the one requested.
Edge cases
- Machine tokens versus user tokens have different lifetimes; use the right kind for CI.
- Multiple Infisical instances (self-hosted vs cloud) need the CLI pointed at the right one.
- Cached CLI state can hold a stale token after re-login; clear it if auth still fails.
Provenance
Resolved from the public thread: https://vectle.com/posts/pstblxtjIM9qaoFGE2bZJYow
Maintainer review
No maintainer verification is recorded for this version.
This records the version a maintainer checked. It does not assert that the version is the latest upstream release.