Troubleshooting | HashiCorp

HASHICORP_SEALED on every authenticated call
Vault is sealed and cannot serve authenticated requests.
Fix: Run system/sealStatus (see System Operations) — it answers even while sealed. Unseal Vault out of band, then retry.

HASHICORP_AUTH_FAILED that "used to work"
Most often a single-use AppRole secret_id that has already been consumed. The credential resolver caches the exchanged client token per credentialID, so calls keep working until that cached token expires — then, with no secret_id left to log in again, every subsequent call fails.
Fix: Reconfigure the AppRole with secret_id_num_uses = 0 (unlimited) for any credential this node authenticates with. See Authentication and Roadmap.

HASHICORP_INVALID_CONFIGURATION
A required config key is missing or malformed: no vaultAddress, authMethod isn't exactly "token" or "appRole", no credentialID, no mount on a Secrets operation, or a namespace with a leading/trailing slash or empty segment.
Fix: Check the exact field list on that operation's page — see Secrets, Token, Lease, or System Operations.

HASHICORP_CAS_MISMATCH on secrets/write
Someone else wrote a newer version at that path since you last read it, or your cas value doesn't match the path's current version.
Fix: Re-read the secret (secrets/read) to get the current version, then retry the write with that value as cas. See Examples #2.

secrets/list returns an empty result for a path you know has keys
Vault returns HTTP 404 for a genuinely empty LIST path, which this node normalizes into an empty success — so an actually-empty folder and a not-yet-created folder look identical in the response.
Fix: Confirm mount/path/engineVersion are exactly right — v1 and v2 list from different underlying Vault paths internally even though the config fields you supply look the same.

secrets/undelete, destroy, readMetadata, or updateMetadata error with no v1 support
These four operations only exist on KV v2. v1 has no versioning or soft-delete concept at all.
Fix: Confirm engineVersion is "2" (the default) for the mount in question, or migrate the mount to v2 if it's still on v1.

HASHICORP_LEASE_NOT_RENEWABLE on lease/renew or token/renewSelf
Some Vault-issued leases and tokens are marked non-renewable by policy — no amount of retrying will make this succeed.
Fix: Use lease/lookup or token/lookupSelf first to check renewable before attempting a renew; if false, the workflow needs a fresh credential/lease instead.

HASHICORP_VAULT_UNREACHABLE
No HTTP response was received at all — DNS failure, connection refused, TLS handshake failure, or a timeout past the retry window (MaxRetries: 2, doubling backoff from 1s).
Fix: Verify vaultAddress is correct and reachable from wherever the workflow executes (network/firewall/VPN), and that its TLS certificate is trusted.

Attempting Transit (encrypt/decrypt), or Kubernetes/LDAP/Okta/JWT/cert auth
None of these exist on this node today — only KV secrets/token/lease/system, and only Token/AppRole auth methods.
Fix: See Roadmap for what's flagged as future scope versus deliberately excluded.