Scripting credential storage into a self-hosted Bitwarden-compatible vault (Vaultwarden) via its official CLI sounds like the safe, structured alternative to hand-typing secrets into the UI. It mostly is — except for one specific, reproducible case where the CLI happily reports success on a login item whose password was never actually saved.
Creating a login item (type: 1 in the CLI's JSON payload) via bw create item,
with the password clearly present in the payload sent, returns a normal success response. Retrieving it
back afterward, though — bw get password <id>, after an explicit bw sync —
returns:
No password available for this login.This isn't the CLI hiding an already-saved password from its own output. The password genuinely was never persisted server-side. Every other field on the item (name, username, URLs) saves correctly — only the password silently vanishes.
collectionIds value pointing at an org collection). A personal item —
created without specifying an organization or collection, landing in your own individual vault space rather
than a shared collection — saves its password correctly every time. Same CLI, same item type, same
payload shape; the only variable that changed the outcome was whether the item landed in a personal vault
or a shared collection.
If you're scripting credential creation against a self-hosted Vaultwarden instance and don't explicitly pass an organization/collection ID, a new item typically lands in your personal vault by default — which happens to avoid this bug. The risk is specifically when automation intentionally (or accidentally, via a default collection an account happens to be scoped into) creates items inside a shared collection.
For anything that must live in a shared collection, use a secure note (type: 2) with the
actual secret written directly into the note's text body, rather than a login item's dedicated password
field. This has been confirmed to save and retrieve correctly every time, including in shared collections
where the login-item path fails. It's a slightly less structured way to store a credential (no dedicated
"password" field to autofill from), but for anything read by automation rather than a browser extension,
that structure isn't actually needed.
For any scripted secret-storage step you're relying on — not just Vaultwarden specifically — add a verification step immediately after creation: read the value back through a separate command, in a fresh session if the tool supports one, and confirm the actual secret matches what you tried to store. A missing or empty result on that read is the only reliable signal that something didn't actually save, regardless of what the write command itself claimed.