SecondBrain/reference/vaultwarden-permission-parity-gotchas.md

---
type: reference
subtype: api-integration
title: "Vaultwarden vs Bitwarden Cloud — permission and feature parity gotchas"
summary: Verified differences between self-hosted Vaultwarden and Bitwarden Cloud that break security designs copied from Bitwarden docs — Edit permission includes delete, no deletion-restriction org policy, no Secrets Manager, trash never auto-purges by default — plus org bot-onboarding gotchas (accept ≠ confirm, collection assignment can silently not persist).
tags:
  - type/reference
  - tool/vaultwarden
  - domain/credential-management
  - domain/security
scope: global
date: 2026-07-09
last_updated: 2026-07-10
last_reviewed: 2026-07-09
related:
  - credvault-integration-master-plan
source: ruby-gems
---

# Vaultwarden Parity Gotchas

Bitwarden's official help docs describe Bitwarden Cloud. Vaultwarden reimplements the server
and does NOT match on these points (verified 2026-07-09, vaultwarden discussions #6131,
issue #6269):

- **Edit collection permission includes deleting items.** There is NO org setting to
  restrict item deletion to Manage-permission members (that toggle is Cloud-only). A "bot
  with Edit but can't delete" design is impossible server-side — enforce in your wrapper/OS layer.
- **Manage permission is worse for least-privilege** — it grants collection-membership admin.
- **Secrets Manager does not exist** in Vaultwarden. Don't plan it as a backend.
- **Trash never auto-purges by default** — permanent deletion only with
  `TRASH_AUTO_DELETE_DAYS` set. (Cloud docs say 30 days.) Safer, but don't cite "30-day window".
- **Password history ("last 5")** is written client-side into the cipher; compatible clients
  preserve it, raw API writes can clobber it. Likely works — verify per instance.
- **`bw` CLI API-key login still requires `bw unlock` + master password** for vault data;
  the API key does not replace the master password. Non-interactive automation needs a
  protected `--passwordfile`.
- **`bw list items --search` doesn't match custom fields** — filter client-side on parsed JSON.
- Maintainer (BlackDex) states Vaultwarden "does not support the full range of RBAC/GBAC/CBAC".

## Org member (bot) onboarding gotchas (verified 2026-07-09, credvault Phase 0)

- **Accept ≠ confirm.** A member who accepts an invite still sees NO organization via
  `bw list organizations` until an org admin explicitly clicks **Confirm** on the member
  (Members page → three-dot menu). Confirm is the step that grants the org key; editing the
  member's role/collections is not it.
- **Collection assignment can silently fail to persist** — after the admin sets a collection
  in Edit member → Collections, `bw list collections` (bot side) can still return `[]` after
  sync. Verify the collection badge shows on the Members list row; re-open the dialog and
  re-save if not.
- **`bw sync -f` after any server-side membership change** — login/unlock state alone won't
  refresh org/collection visibility on the client.
- **Password history verified working** on Vaultwarden: `bw edit` with a changed login
  password preserves the old one in `passwordHistory` with `lastUsedDate`. Custom `fields`
  round-trip intact through `bw list items` JSON.

## Credential rotation gotchas (verified 2026-07-10, credvault e2e)

- **Master password rotation invalidates cached `bw` logins.** After changing an account's
  master password server-side, `bw unlock` fails (exit 1) even with the correct new
  `--passwordfile` — the cached login holds keys derived from the old password. Fix:
  `bw logout`, then re-login with the API key, then unlock works.
- **`bw` sessions are per `BITWARDENCLI_APPDATA_DIR`.** A plain `bw logout` in a shell only
  clears the *default* appdata dir; tool-specific dirs (e.g. credvault's
  `~/.config/credvault/bitwarden`) keep their stale session until you log out with the
  matching env var set.
- **API key rotation changes only `client_secret`** — `client_id` is stable across rotations.
- **`bw unlock --passwordfile` reads only the first line**, so a trailing newline from an
  editor (nvim etc.) is harmless.

Rule of thumb: any "Bitwarden supports X" claim from bitwarden.com/help must be re-verified
against the deployed Vaultwarden version before it becomes a security assumption.