Summary
Today the extension treats the connected Bitwarden session as a single flat vault. Organization-owned items are surfaced (we already parse organizationId on every item) but there's no first-class concept of which organization they belong to, no collection awareness, and no support for users with multiple Bitwarden accounts (e.g. personal + work).
Current state
BitwardenCliService.cs only calls bw list items and bw list folders. We never call bw list organizations or bw list collections, so we don't know org names or collection structure - only the raw organizationId GUID on each item.
- The existing
org: advanced search filter (BitwardenCliService.cs:1130) matches against that GUID, which is unusable in practice (no human ever types a GUID).
- The Bitwarden CLI itself is single-account: one
bw login / BW_SESSION at a time. Users who want personal + work accounts have to log out and log in again to switch.
Asks (in priority order)
- Surface org names on items. Cache
bw list organizations at unlock and tag items with the resolved org name. Show the org as a subtitle/tag on list rows so users can tell at a glance whether they're about to copy from their personal vault or a shared org item.
- Filter / group by organization. Replace the GUID-based
org: filter with name-based matching, and consider an organization picker (similar to folders) or section headers grouping items by org.
- Collection awareness. Pull
bw list collections and surface collection membership on items (multi-collection is possible). Useful for users with large orgs where folders alone aren't enough.
- Multi-account switching. Allow the extension to manage more than one Bitwarden account, switching the active session on demand. This is the most invasive: the CLI doesn't support concurrent sessions, so we'd need to persist credentials/sessions per account and re-issue
bw login / bw unlock on switch. Possibly out of scope until upstream CLI grows multi-account support.
Open questions
- How do collections interact with the master password re-prompt flag we already handle?
- For multi-account: is it worth pursuing given Bitwarden Desktop already supports it, or wait for
bw CLI support?
Summary
Today the extension treats the connected Bitwarden session as a single flat vault. Organization-owned items are surfaced (we already parse
organizationIdon every item) but there's no first-class concept of which organization they belong to, no collection awareness, and no support for users with multiple Bitwarden accounts (e.g. personal + work).Current state
BitwardenCliService.csonly callsbw list itemsandbw list folders. We never callbw list organizationsorbw list collections, so we don't know org names or collection structure - only the raworganizationIdGUID on each item.org:advanced search filter (BitwardenCliService.cs:1130) matches against that GUID, which is unusable in practice (no human ever types a GUID).bw login/BW_SESSIONat a time. Users who want personal + work accounts have to log out and log in again to switch.Asks (in priority order)
bw list organizationsat unlock and tag items with the resolved org name. Show the org as a subtitle/tag on list rows so users can tell at a glance whether they're about to copy from their personal vault or a shared org item.org:filter with name-based matching, and consider an organization picker (similar to folders) or section headers grouping items by org.bw list collectionsand surface collection membership on items (multi-collection is possible). Useful for users with large orgs where folders alone aren't enough.bw login/bw unlockon switch. Possibly out of scope until upstream CLI grows multi-account support.Open questions
bwCLI support?