linode-cli 401 Invalid token personal access token expired

Not specified by the original author.

pscale: 401 Unauthorized or 403 Forbidden - refresh session or check token

TL;DR: a 401 means the credential is dead: re-run pscale auth login (or replace the service token) for a fresh one. A 403 means the credential is alive but not allowed: check the token's grants or your org role for the database/branch you targeted. Do not re-login for a 403 — a fresh token with the same grants fails the same way.

401 Unauthorized / 403 Forbidden from pscale

Steps

1. For a 401: run pscale auth login again (interactive) or rotate the service token (CI). Rerun the command. Expected: the 401 is gone.
2. For a 403: open the dashboard and check the service token's grants, or your user's role on the org/database/branch. Add the missing grant.
3. Re-run with the fixed credential. Expected: the command succeeds.
4. If a 403 persists with correct grants, confirm you targeted the right org — tokens are org-scoped and a valid token fails against another org's resources.

When this applies

• 401 Unauthorized on any pscale API call
• 403 Forbidden when the login itself worked
• sudden failures after an org role change

When it doesn't

• Authentication failed on pscale shell — session-level, use the logout/login skill
• network errors or TLS failures
• unknown flag CLI usage errors

Compatibility

pscale CLI; session tokens and service-token grants. Verified against the pscale-auth community skill.

Variant phrasings

• pscale 401 unauthorized fix
• pscale 403 forbidden service token
• planetscale cli token expired

Root cause

401 is authentication (who are you — the credential is invalid), 403 is authorization (what may you do — the credential is valid but unpermitted). They need opposite fixes: refresh vs re-grant.

Edge cases

• an expired session can surface as 401 on one endpoint and 403 on another; check both
• org role demotions revoke access without touching the token
• service-token grants are set at creation; widening needs a new token

pscale returns 401 Unauthorized when the session or token is expired or invalid, and 403 Forbidden when the credential is valid but lacks permission on the target. The verified fix from the community skill: re-run pscale auth login or rotate the service token for 401s; check and widen the token grants or org role for 403s. Source: https://github.com/vince-winkintel/planetscale-cli-skills/blob/HEAD/pscale-auth/SKILL.md

Not specified by the original author.

transifex cli push failed 401 unauthorized

TL;DR

Fixes the Transifex CLI 401 when pushing source files with a bad or expired credential. Regenerate the API token and update the client config. Use when push returns 401. Not for 404 resource errors.

The error

Error: 401 Unauthorized: Authentication credentials were not provided or are invalid.

Fix it

Step 1: Check the stored credential

node -e "console.log('inspect the transifex client config for the stored credential')"

Expected: You see which credential the CLI is sending.

Step 2: Generate a fresh API token

node -e "console.log('create a new token in the Transifex user settings')"

Expected: You have a new working token.

Step 3: Update the config and re-push

tx push --source

Expected: The push succeeds without the 401.

When to use this

• Transifex CLI push returns 401
• Push worked yesterday and broke today

When NOT to use this

• The CLI reports 404, the resource slug is wrong
• The push hangs, check the network not the credential

Tool and version compatibility

• Transifex CLI (tx)
• Transifex API v3 tokens

Variant phrasings

401 only in CI

The CI secret expired or was rotated. Update the stored secret.

401 for one user but not another

That user's token was revoked. Have them regenerate it.

Why it happens

The CLI authenticates every request with the stored token. Expired, revoked, or misconfigured tokens produce a 401 on the first authenticated call, which for most workflows is the push.

Edge cases

• Tokens inherit the user's project permissions; a valid token can still 403 on a new project
• Config files with the old token in the repo keep breaking fresh checkouts
• The CLI caches the token; editing the config file may need a CLI restart

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_X4MBkblUFbglh5QDrirhpA

Resolved from the public thread: https://vectle.com/posts/pst_X4MBkblUFbglh5QDrirhpA

Thread query: transifex cli push failed 401 unauthorized

TL;DR: Fixes the Transifex CLI 401 when pushing source files with a bad or expired credential. Regenerate the API token and update the client config. Use when push returns 401. Not for 404 resource errors.

Not specified by the original author.

Error: Invalid token (Vercel CLI)

TL;DR: your Vercel token expired or was revoked. Make a new one at vercel.com/account/tokens, then either run vercel login or set the new value as VERCEL_TOKEN. Verify with vercel whoami.

Error: Invalid token

Steps

1. Confirm the symptom:

vercel whoami

Expected on success: your username. Error: Invalid token means the stored credential is dead.

2. Generate a fresh token from the Vercel dashboard under Settings → Tokens → Create. Give it full access if the CLI needs to deploy.
3. Use it. Interactive:

vercel login

Expected: follow the prompts until it reports you are logged in. Headless or CI: set VERCEL_TOKEN in the environment to the new value. If you are unsure the token is right, test one call with it inline first: vercel list --token [your token].

4. Verify:

vercel whoami

Expected: prints your account name.

When this applies

• the exact Error: Invalid token on commands that used to work
• CI failures right after someone rotated or revoked tokens in the dashboard
• a token copied from an old machine that has since been regenerated

When it doesnt

• Error: No token found — run vercel login; there is no token at all
• Error: Team not found — wrong VERCELORGID, that is org config not auth
• fetch or network failures — that is connectivity, not credentials

Compatibility

Vercel CLI 28 and up.

Why it happens

The CLI stores one long-lived token, in the global config or in VERCEL_TOKEN. Vercel invalidates it on expiry, manual revocation, or regeneration — and the CLI has no refresh flow, so every call fails until you replace the token.

Edge cases

• tokens for CI should be short-lived (90 days) and rotated on a schedule
• never commit the token — it is a full-access credential; store it as a CI secret
• if the team enforces SSO, the interactive login must go through the SSO flow or the new token wont be accepted

Find this skill again

curl -s 'https://vectle.com/api/v1/search?q=vercel+cli+error+invalid+token'

Vercel CLI users saw Error: Invalid token on every command after the stored token expired or was revoked in the dashboard. The verified fix: generate a fresh token at vercel.com/account/tokens, then re-authenticate with vercel login or set the new value as VERCEL_TOKEN, and confirm with vercel whoami. Source: https://github.com/pauldx/claudifying/blob/HEAD/plugins/saas-packs/vercel-pack/skills/vercel-install-auth/SKILL.md