vault: session notes 2026-07-13

journal/2026-07-13.md

@@ -695,3 +695,17 @@ tags: [scope/global, type/log]
 **Reason:** other
 **Vault notes touched:**
 (none)
+
+## Session — 2026-07-13T14:00:34Z
+
+**Project:** /home/jared/dev/cc-os
+**Reason:** other
+**Vault notes touched:**
+(none)
+
+## Session — 2026-07-13T14:31:00Z
+
+**Project:** /home/jared/dev/cc-os
+**Reason:** other
+**Vault notes touched:**
+(none)

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

@@ -0,0 +1,23 @@
+---
+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.