SecondBrain/reference/credvault-locked-status-is-not-blocking.md

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

## Related

- [[credvault-bulk-call-behaviors]]

2026-07-13 (later): codified into the credential-management skill (cc-plugins v0.1.1) — SKILL.md preflight + cli-reference status section now state this rule explicitly, after a second field incident of a session parking work in Waiting over status-locked.