Self-Hosting / Automation

The Bitwarden CLI Can Report Success While Silently Dropping a Password

Scripting secrets into Vaultwarden with the official Bitwarden CLI sounds safer than typing them into the UI. It mostly is.

But there is one reproducible case where the CLI reports success on a login item whose password was never saved.

The symptom

Create a login item with command bw create item, using type: 1 and the password clearly present in the payload. You get a normal success response.

Run bw sync, then read it back with command bw get password <id> and you get this.

No password available for this login.

This is not the CLI hiding a saved password from its own output. The password was never persisted server-side.

Every other field saves correctly. Name, username, URLs. Only the password vanishes.

The actual trigger: shared/organization collections specifically

BE WARNED: this only reproduces when the item lands in a shared organization collection. That means an item with a real collectionIds value pointing at an org collection.

A personal item saves its password correctly every time. Same CLI, same item type, same payload shape. The only variable that changed the outcome was personal vault against shared collection.

If your script does not pass an organization or collection ID, a new item usually lands in your personal vault. That avoids the bug by accident.

The risk is automation that writes into a shared collection, either on purpose or because the account is scoped into one by default.

The workaround that's confirmed reliable

For anything that must live in a shared collection, use a secure note with type: 2 and write the secret into the note body. Do not use a login item's password field.

This saves and retrieves correctly every time, including in the shared collections where the login item fails.

You lose the dedicated password field to autofill from. For a secret read by automation rather than a browser extension, you do not need it.

The general rule

Never trust a credential manager's own success response as proof a secret saved. Read it back independently, every time it matters. This is the same failure as an API reporting a change applied when it silently was not. Write-path validation and actual persisted state can disagree. The only way to know is a separate read.

Add a verification step after any scripted secret write. This is not specific to Vaultwarden.

Read the value back through a separate command, in a fresh session if the tool supports one. Confirm the secret matches what you tried to store.

A missing or empty result on that read is the only reliable signal that something did not save, whatever the write command claimed.