neonctl auth errors: re-run neonctl auth to re-authenticate

neonctl auth errors: re-run neonctl auth to re-authenticate

TL;DR: neonctl caches credentials locally, and the cache goes stale when keys rotate, accounts switch, or sessions expire. Re-run neonctl auth to redo the login flow and overwrite the cache with fresh credentials. If errors persist, delete the cached credential files so nothing stale survives, then authenticate again.

neonctl auth errors after previously working

Steps

1. Run neonctl auth and complete the login flow. Expected: the CLI confirms the new authentication.

1. Rerun the failing command. Expected: auth succeeds.

1. Still failing: remove the cached credentials (the CLI's local credential store) and run neonctl auth once more from clean state.

1. If you switched accounts, confirm the new login matches the account that owns the target project.

When this applies

• auth errors appearing with no config change on a previously working setup
• failures right after switching Neon accounts in the browser
• Authentication failed that survives a key check (the cache may hold the old key)

When it doesn't

• first-time setup where no credentials were ever stored
• keys revoked server-side — re-auth with the same dead key changes nothing
• CI environments, which should use NEONAPIKEY instead of cached auth

Compatibility

neonctl; the local credential cache; neonctl auth. Verified against the community neonctl skill notes.

Variant phrasings

• neonctl re-authenticate
• neonctl auth errors fix
• neonctl stale credentials

Root cause

The CLI reads credentials from its local cache first. When the cached value no longer matches the account state (rotation, expiry, account switch), every call fails until the cache is refreshed — the config files you keep checking were never the problem.

Edge cases

• two CLIs (neon vs neonctl) can keep separate caches; fix the one you actually invoke
• NEONAPIKEY in the environment overrides the cache, which can mask a stale cache locally
• on shared machines, the cache belongs to the OS user; sudo runs see a different one