2026-07-13 14:31:00 +00:00
|
|
|
---
|
|
|
|
|
summary: Why credvault status showing a locked vault does not mean credvault operations will fail — per-operation auto-unlock behavior.
|
|
|
|
|
tags:
|
|
|
|
|
- type/reference
|
|
|
|
|
- tool/credvault
|
|
|
|
|
scope: global
|
|
|
|
|
date: 2026-07-13
|
|
|
|
|
---
|
|
|
|
|
|
|
|
|
|
# credvault "locked" status is not blocking
|
|
|
|
|
|
|
|
|
|
`credvault status` reporting `login_state: locked` / `vault_locked: true` does **not** mean
|
|
|
|
|
operations will fail. credvault auto-unlocks per operation using its secured master-password
|
|
|
|
|
file (`master_password_file_secure: true` in the same status output). "Locked" only means
|
|
|
|
|
there is no persistent session held between commands — by design.
|
|
|
|
|
|
|
|
|
|
Verified 2026-07-13: with status showing locked, an idempotent `credvault ensure` on an
|
|
|
|
|
existing key succeeded (`"result": "existing"`).
|
|
|
|
|
|
|
|
|
|
**Rule of thumb:** don't treat status-locked as a blocker or ask the human to unlock. Only a
|
|
|
|
|
genuine `authentication_failed` / `vault_locked` **error returned by an operation** requires
|
|
|
|
|
human intervention — and per the credential-management skill, never attempt to fix vault
|
|
|
|
|
auth yourself.
|
2026-07-13 17:08:02 +00:00
|
|
|
|
|
|
|
|
## Related
|
|
|
|
|
|
|
|
|
|
- [[credvault-bulk-call-behaviors]]
|
