## 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

```text
"infisical: unauthorized" api error
```

## Steps

1. Check whether a token is configured for the CLI at all. Expected: you see whether auth state exists.
2. Re-authenticate to get a fresh token. Expected: login succeeds.
3. Verify the token's project and environment scope includes what you are accessing. Expected: scope matches.
4. If using a service token, confirm it has not been revoked or rotated. Expected: the token is live.
5. 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/pst_blxtjIM9qaoFGE2_bZJYow