Your Bitwarden vault in the Omarchy status bar. Search, copy, and manage every item type without opening a browser.
Built on Quickshell and the official Bitwarden CLI. Keyboard-first, fast, and it never writes your vault to a cache of its own.
One command. It clones the plugin, enables it, and puts it in the bar:
omarchy plugin add https://github.com/Elevate08/qs-bitwarden-cli --enableNothing else has to be installed first. Open the panel and it tells you what it
still needs -- on a stock Omarchy install that is the Bitwarden CLI and jq --
with an Install button that hands off to Omarchy's own installer.
To update: omarchy plugin update io.github.elevate08.qs-bitwarden-cli
Email and password, with the 2FA prompt appearing only when Bitwarden asks for one. Server region picks US, EU, or a custom URL for self-hosted Bitwarden and Vaultwarden.
Using SSO, a Duo push, or a hardware key? Launch Terminal runs bw login in
a real terminal so Bitwarden's own prompts handle it, then hands the session
straight back to the panel -- no second login just to get in.
Search by name, username, URL, public key or fingerprint. Enter copies the password and arms the TOTP follow-up; press it again within the window and the live 2FA code replaces it on the clipboard.
Items show their folder and organization inline. The bottom bar filters by folder, organization and type without leaving the keyboard.
Suggestions read the focused window or browser tab and pin the matching credential to the top, so Enter is usually the only key you need. Pick an item once for a site a title cannot match, and it is remembered.
Suggestions come from the window title, because that is all Hyprland
exposes -- not the tab's real address. A page chooses its own title, so a
phishing page titled github.com is suggested your GitHub login just like
the real one. Check the address bar before you paste; unlike browser
autofill, this is no defence against a look-alike site.
f, o and t open the folder, organization and type drawers. Arrows move, Enter applies, Esc closes -- and the cursor starts on the option already in effect, so Enter never changes anything by accident.
Username, password and the live TOTP with its countdown, the websites attached to the item, its notes and any custom fields. Copy any of them with one key.
Suggest here pins this item for the app or site in front of you, so it is offered outright next time rather than inferred.
Cards show cardholder, brand, number, expiry and security code. The number and the code are masked until revealed, and each reveals independently -- an eye is a statement about the field it sits on.
Search finds a card by brand, cardholder, or last four digits. Deliberately not by the middle of a number.
Identities show name, username, company, email and phone, the social security, passport and licence numbers, and the address as a single copyable block rather than seven rows. Empty fields are not drawn, so a sparse identity stays short.
The three identifiers are masked for the reason a password is, with the difference that these cannot be rotated afterwards.
Create logins, secure notes, cards and identities. Enter saves from anywhere in the form, so a long item does not have to be scrolled to the bottom.
Saving and deleting no longer hold the panel. The form closes as the command is launched and the row shows a spinner until the vault answers. If the vault refuses, the list goes straight back to what it actually holds and offers to reopen what you typed.
Every option the browser extension has -- length, character classes, minimums, ambiguous characters, or a passphrase with a word count and separator -- with a live strength meter.
Generation comes from Bitwarden's own generator, not a reimplementation, and
answers in about 2ms rather than the ~2.9s a fresh bw generate costs.
Share a secret through a link that expires on its own, so a credential need not live in a chat log. Set a deletion window, a view limit and an optional password; the link is copied the moment it is created.
Opt-in. Serves the SSH keys in your vault to ssh, Git and ssh-keygen -Y sign
while the vault is unlocked, from a helper process that holds the private keys
in memory -- never on disk, never in QML.
Every signature says what is being signed and names the key, its fingerprint and the program asking. One approval can cover a whole rebase -- and only the rebase's signatures; live grants are listed and revocable.
Setup, verification and threat model →
Grouped into General, Security and SSH Agent, with the section you are reading pinned above the list as you scroll. Destructive actions sit under their own DANGER ZONE heading.
Changes are written to the plugin's entry in ~/.config/omarchy/shell.json
through omarchy bar set, so Omarchy owns the file and the shell hot-reloads.
The General settings include Colorize menu-bar icon, which makes the primary Bitwarden shield follow the active Omarchy theme accent. It is off by default; lock and setup/error indicators keep their existing status colors.
What this plugin does, next to the two official Bitwarden clients a Linux user would otherwise reach for. Checked against Bitwarden's documentation on 2026-12-01.
| This plugin | Bitwarden CLI | Bitwarden Desktop | |
|---|---|---|---|
| Lives in the Omarchy bar | ✅ | ❌ | ❌ |
| View logins, notes, cards, identities | ✅ | ✅ | ✅ |
| Create / edit logins, notes, cards, identities 1 | ✅ | ✅ | ✅ |
| View SSH key items | ✅ | ✅ | ✅ |
| Create / import SSH keys 2 3 | ❌ | ❌ | ✅ |
| SSH agent 4 | ✅ | ❌ | ✅ |
| TOTP codes, auto-copied after the password 5 | ✅ | ❌ | ❌ |
| Download attachments | ✅ | ✅ | ✅ |
| Bitwarden Send, text | ✅ | ✅ | ✅ |
| Folders, collections, organizations | ✅ | ✅ | ✅ |
| Password / passphrase generator | ✅ | ✅ | ✅ |
| Unlock with PIN 6 | ✅ | ❌ | ✅ |
| Unlock with fingerprint 7 8 9 | ✅ | ❌ | ✅ |
| Unlock with FIDO2 key 10 | ✅ | ❌ | ❌ |
| Auto-lock on idle, screen lock, suspend 11 12 | ✅ | ❌ | ✅ |
| Suggests by focused window / browser tab | ✅ | ❌ | ❌ |
| Self-hosted and Vaultwarden | ✅ | ✅ | ✅ |
| Import / export your vault 13 | ❌ | ✅ | ✅ |
| Trash: restore a deleted item 14 | ❌ | ✅ | ✅ |
| Upload attachments 15 | ❌ | ✅ | ✅ |
| File Sends 16 | ❌ | ✅ | ✅ |
| View / edit custom fields 17 | ✅ | ✅ | ✅ |
| Organization admin: confirm members, approve devices 18 | ❌ | ✅ | ❌ |
Sources: CLI · SSH agent · About SSH · PIN unlock · Biometrics
The panel opens with the item list focused, so single-letter shortcuts work straight away. Press / to type a search.
While the search box has focus every letter is search text -- as a text field should behave. Hold Alt to reach the same shortcuts without leaving the box or disturbing your query; ↓ also hands focus back to the list.
| Shortcut | Action |
|---|---|
| Enter | Copy password (and arm the TOTP follow-up), or open the item when there is no password to copy -- a card, an identity, a note, an SSH key |
| Enter (again) | Copy the TOTP code during the follow-up window |
| ↑ / ↓ / j / k | Move through items, or through an open filter drawer |
| / | Focus the search box |
| Tab / Shift+Tab | Cycle types without opening the drawer |
| p (or y) | Copy password |
| u (or c) | Copy username / email |
| m | Copy TOTP multi-factor code |
| w | Open the website in your browser |
| e | Open the detail inspector / edit |
| f | Folders filter |
| o | Organizations filter |
| t | Types filter |
| g | Generator |
| n | New vault item |
| s | Settings |
| r | Sync (refresh) |
| l | Lock the vault |
| Alt+s | Bitwarden Send |
| Alt+, | Settings |
| Esc | Close the filter drawer, clear the search, or close the panel |
Alt + any letter above runs the same action from inside the search box. Two are Alt-only: Alt+s opens Send (which has no bare letter, since s is Settings), and Alt+, opens Settings, so Settings is still reachable while searching.
| Shortcut | Action |
|---|---|
| Enter / y / p | Copy what the item is for: the password on a login, the number on a card |
| u / c | Copy username; on an identity u is the username and c the email |
| n | Copy a card's number |
| k | Copy a card's security code |
| m | Copy TOTP code |
| v | Toggle reveal on the item's principal secret -- the password on a login, the number on a card. Every other masked field has its own eye, and each reveals independently |
| a | Save every attachment on this item |
| e | Edit this item |
| x | Delete this item (asks first) |
| b / q / Esc | Back to the list |
| Shortcut | Action |
|---|---|
| f / o / t | Open (or close) that drawer |
| ↑ / ↓ | Move through the options |
| Enter | Apply the highlighted option |
| Esc | Close without changing anything |
The cursor starts on the option already in effect, so Enter never changes a filter by accident.
| Shortcut | Action |
|---|---|
| ↑ / ↓ | Move between settings |
| ← / → | Decrease / increase a number by its step, or switch a toggle off / on |
| Enter | Flip the highlighted toggle, or open the PIN / fingerprint form |
| Esc | Back |
| Shortcut | Action |
|---|---|
| Alt+s | Open Sends |
| n | New Send |
| r | Refresh the list |
| x | Delete the highlighted Send |
| Enter | Copy the highlighted Send's link |
| Esc | Back |
PIN, fingerprint and FIDO2 unlock all need your master password, because bw unlock accepts nothing else. The plugin keeps it once, in a single keyring item (service=qs-bitwarden-cli, account=unlock_envelope):
- The first time
bwaccepts a password you typed -- a login, or unlocking with your master password -- it is encrypted under a random key with XChaCha20-Poly1305, and the whole item is sealed to this machine and your user withsystemd-creds --user. A copy taken off this machine is useless. - Each unlock method you turn on adds its own way to that one key, and none of them stores the password again. Turning a method off removes only its way in.
- The master password you are asked for when turning a method on is a check against the stored one, not a new copy: a wrong one is refused, and nothing you type there is stored.
- If you change your master password elsewhere, the next unlock with the new one re-seals the stored copy and keeps every method.
- Logging out deletes it.
The small helper that does the encryption (bin/x86_64-linux/qs-bitwarden-unlock-key) ships and is verified exactly like the SSH helper; if it is missing or fails its check, quick unlock is unavailable and your master password still works. Everything else is the operating system: argon2, systemd-creds, fido2-assert and secret-tool.
Upgrading from 1.10.0 or earlier needs nothing from you. The old entries -- a plaintext copy for fingerprint and for FIDO2, an encrypted one for the PIN -- are moved in as each method is next used, and deleted once the new copy opens.
The honest limit. The stored password is only as protected as the weakest method you have turned on, and the settings screen says so. A fingerprint releases no secret to encrypt with, so with fingerprint unlock on, a program running as you while you are logged in can open it. A PIN or a FIDO2 key cannot be bypassed that way; root, as always, can read anything.
Turn on Unlock with PIN in the settings screen. Confirm your master password and choose a PIN. Six digits or more is what the screen asks for; four and five are accepted but shown with the real cost of guessing them, so a weak PIN is a decision rather than an accident.
The PIN reaches the stored password through Argon2id (256 MiB of memory, 4 passes, about 0.75 s of one CPU core per guess), from the OS argon2 tool. Because the stored item is sealed to this machine, guessing has to happen here, as you: roughly 2 hours of one core for 4 digits, 21 hours for 5, and 9 days for 6. A wrong PIN always fails -- the encryption is authenticated, so there is no "decrypts to garbage" case.
Five wrong attempts at the panel removes the PIN's way in, and turning it back on needs your master password. That is a limit on the screen, not on a copy of the keyring; the Argon2 cost is what stands behind it.
Set fingerprintUnlock to true to unlock the vault with a finger instead of your master password.
Requirements
- A fingerprint reader with at least one enrolled finger, configured through
omarchy setup security fingerprint. The plugin verifies all of this itself (/etc/pam.d/omarchy-lock-fingerprint,fprintd-list) and silently stays hidden when any part is missing. - A running, unlocked OS keyring, as used by
rememberSession. Omarchy ships libsecret itself, so there is nothing to install for this.
How it works
- Switch Unlock with fingerprint on in the settings screen and confirm your master password.
- On every later lock, opening the panel arms the reader. A verified fingerprint opens the stored password for
bw unlock; the password field remains available as a fallback at all times.
Security trade-off -- read before enabling
PAM can prove that you are present, but a fingerprint releases no secret, so it cannot encrypt anything by itself. Fingerprint unlock is the one method whose way in is protected only by the machine seal, which means a program running as you while you are logged in can open the stored password without your finger. This is the same trade the official Bitwarden desktop client makes for its own biometric unlock. It is off by default and worth leaving off on a shared or unattended machine -- and with it on, a PIN or a key does not make the stored password any safer.
Its way in is removed when you turn the setting off, press Forget Fingerprint on the locked screen, or log out.
A closed lid takes the option off the screen. The reader is on the laptop body, so with the lid shut -- clamshell mode, or simply closed on a docked machine -- there is nothing to touch. While it is down, the locked screen hides Unlock with Fingerprint, the SSH prompt does the same, and the reader is not armed on open. Omarchy's own detector (omarchy-hw-laptop-closed) decides, and a machine with no lid never reports one. Nothing is forgotten: the settings toggle is unchanged, and the option is back the moment the lid opens. A FIDO2 key on a cable is unaffected.
Set fidoUnlock to true to unlock the vault with a FIDO2 authenticator (a YubiKey or any other compliant key) instead of your master password.
Requirements
- A FIDO2 key registered through
omarchy setup security fido2. That one command detects the key, installslibfido2/pam-u2f, registers it, and wires it for the system's own authentication prompts; the plugin uses that same registration (/etc/fido2/fido2) and offers the command itself when no key is registered yet. The option stays hidden on a machine with no key. - A key that supports the
hmac-secretextension, which current YubiKeys and most FIDO2 keys do.
How it works
- Switch Unlock with FIDO2 key on in the settings screen. If no key is registered, it first hands off to
omarchy setup security fido2; otherwise confirm your master password and touch the key once. - On every later lock, opening the panel arms the key if one is plugged in (falling back to the fingerprint reader otherwise). One touch asks the key for a secret only it can produce -- its
hmac-secretfor the registered credential -- and that secret opens the stored password. The password field remains available as a fallback at all times.
The key will not produce that secret without a touch, so unlocking needs the key itself, not just a program able to read your keyring. Each registered key that is plugged in when you turn the option on gets its own way in, so a backup key works too.
Registrations made with +pin or +verification (a key PIN at every system prompt) are not used: the panel cannot collect the key's PIN yet, and a touch alone would be weaker than what the registration asks of the system.
Its way in is removed when you turn the setting off, press Forget FIDO2 Key on the locked screen, or log out. omarchy remove security fido2 unregisters the key for the system's own authentication prompts as well, which is why the plugin points at Omarchy's setup rather than registering the key itself.
Off by default. See docs/ssh-agent.md for setup, the provenance check, and what the agent does and does not protect.
--enable already puts the widget in the bar. To move it:
omarchy bar move io.github.elevate08.qs-bitwarden-cli --section rightSettings are editable from the panel's own settings screen, or directly in
~/.config/omarchy/shell.json. Each setting lives inline on the bar entry,
not in a separate block:
{
"bar": {
"layout": {
"right": [
{
"id": "io.github.elevate08.qs-bitwarden-cli",
"autoLockMinutes": 15,
"lockOnScreenLock": true,
"lockOnSuspend": true,
"clearClipboardSec": 30,
"rememberSession": true,
"fingerprintUnlock": false,
"fidoUnlock": false,
"sshAgentEnabled": false,
"sshAgentApprovalPopup": true
}
]
}
}
}To toggle the Bitwarden panel with a keyboard shortcut (e.g. SUPER + CTRL + /), add the binding to ~/.config/hypr/bindings.lua:
o.bind("SUPER + CTRL + SLASH", "Bitwarden vault", "omarchy-shell io.github.elevate08.qs-bitwarden-cli toggle")Apply changes by restarting the shell:
omarchy restart shellThe following settings are read from the plugin's own entry in the
bar.layout array of ~/.config/omarchy/shell.json -- inline alongside its
id, as shown above. The panel's settings screen writes them for you via
omarchy bar set, so editing the file by hand is optional:
| Key | Type | Default | Description |
|---|---|---|---|
autoLockMinutes |
number |
15 |
Minutes of inactivity before automatically locking the vault (0 to disable). Range 0-1440; out of range is clamped and an unreadable value falls back to 15. |
clearClipboardSec |
number |
30 |
Seconds before automatically clearing copied secrets from the clipboard (0 to disable). Range 0-300; out of range is clamped and an unreadable value falls back to 30. |
lockOnScreenLock |
boolean |
true |
Lock the vault as soon as the screen locks, rather than waiting out autoLockMinutes. Reads the Omarchy lock screen's own state, so it follows a manual lock and an idle lock alike. A shell without the lock plugin simply never reports a lock; it is never read as one. |
lockOnSuspend |
boolean |
true |
Lock the vault when the machine is going to sleep, so no unlocked session key is left in the suspended machine's memory. Holds a delay sleep inhibitor for about a second so the lock finishes first. Needs gdbus (glib2), systemd-inhibit and setsid (util-linux). The monitor and its children stop when the plugin unloads; without these tools the setting is inert. |
rememberSession |
boolean |
true |
Persist session token in OS keyring (secret-tool) while unlocked. Survives a shell restart, never a reboot -- see the note above. |
autoCopyTotpSec |
number |
3 |
Seconds after password copy to automatically replace clipboard with TOTP code (0 to disable). Range 0-30; out of range is clamped and an unreadable value falls back to 3. |
closeOnCopy |
boolean |
true |
Automatically close panel on Enter copy so target application receives focus immediately. |
suggestOnOpen |
boolean |
true |
Automatically suggest matching vault items for the active window or browser tab on open. |
fingerprintUnlock |
boolean |
false |
Unlock the vault with an enrolled fingerprint. Adds a way into the one encrypted stored password -- see Fingerprint unlock for its limit. |
fidoUnlock |
boolean |
false |
Unlock the vault with a FIDO2 authenticator, on the registration omarchy setup security fido2 writes. The key's hmac-secret opens the stored password -- see FIDO2 key unlock. |
pinUnlock |
boolean |
false |
Unlock with a numeric PIN, through Argon2id -- see PIN unlock. |
sshAgentEnabled |
boolean |
false |
Serve your vault's SSH keys to ssh, Git and signing while the vault is unlocked. Starts a helper process and a socket under $XDG_RUNTIME_DIR; private keys stay in that helper and are dropped on lock -- see SSH Agent. |
sshAgentUnlockOnDemand |
boolean |
false |
Let an identity listing raise the unlock prompt when the vault is locked and no keys have been loaded yet, instead of answering with an empty list. Signing a key the helper already knows always raises the prompt, with or without this. Off by default: ssh asks the agent for identities on every connection, so this raises the configured approval surface on the first ssh after every login. |
sshAgentApprovalPopup |
boolean |
true |
Show SSH unlock and signing requests in a transient card in the middle of the screen instead of opening the anchored panel. Disable to show prompts in the panel. Multiple concurrent requests are queued sequentially with a "1 of N" counter and "Deny all" option. Escape and outside click deny. |
sshAgentApprovalWindowSec |
number |
120 |
How long one approval keeps covering further signatures from the same program with the same key. Range 0-900; 0 asks every time. Held in memory only and dropped on lock, logout or exit. |
One further key, twoFactorMethods, is written to the same entry but is not a
setting you configure. It records which two-step method last logged each
account in, keyed by login address -- {"you@example.com": 0}, where 0 is
authenticator, 1 email and 3 YubiKey -- so an account with more than one
method is asked only once, and two vaults on one machine each keep their own
answer. Change method on the code screen asks again and rewrites it. Entries
are capped at ten accounts, and anything unreadable is treated as not
remembered, which costs that account one extra prompt.
Learned suggestions are stored separately in ~/.local/state/qs-bitwarden-cli/associations.json. Delete that file to reset everything the panel has learned; logging out deletes it for you.
Omarchy draws its bar once per monitor, so the widget appears on every one of them -- but there is one vault behind them all:
- Unlocking or locking on any monitor applies to all of them, and every bar's icon shows the same state.
- The panel opens on the monitor whose icon you click, and moving to another monitor's icon moves the open panel there, where you left it. A keyboard summon lands on the focused monitor, or on the panel if it is already open.
- There is one SSH agent, one sleep inhibitor and one IPC target however many monitors are attached. A signing request appears on the monitor with the open panel, or otherwise the focused one.
- Unplugging a monitor, even the one showing the panel, leaves the vault and the agent running.
If something else on the machine is already serving the agent's socket -- a second Omarchy shell, for example -- the SSH agent settings say so and wait for it to stop, rather than reporting a helper that keeps failing to start.
A bar other than Omarchy's own cannot share one vault between its copies, so on a replacement bar each monitor's widget keeps a vault of its own, as before.
You can control and query the Bitwarden plugin from the terminal, scripts, or window manager bindings. The form is omarchy-shell <target> <method>:
# Show, hide, or toggle the popup panel
omarchy-shell io.github.elevate08.qs-bitwarden-cli open
omarchy-shell io.github.elevate08.qs-bitwarden-cli close
omarchy-shell io.github.elevate08.qs-bitwarden-cli toggle
# Jump straight to a screen
omarchy-shell io.github.elevate08.qs-bitwarden-cli settings # -> "settings"
omarchy-shell io.github.elevate08.qs-bitwarden-cli setup # -> "setup" (dependency wizard)
# Lock the vault immediately
omarchy-shell io.github.elevate08.qs-bitwarden-cli lock # -> "locked"
# Sync with Bitwarden
omarchy-shell io.github.elevate08.qs-bitwarden-cli sync # -> "syncing"
# Query vault state
omarchy-shell io.github.elevate08.qs-bitwarden-cli status # -> "unlocked" | "locked" | "unauthenticated"
# Which vault the bars share, and which monitor presents it (non-secret)
omarchy-shell io.github.elevate08.qs-bitwarden-cli vaultHost # -> {"host":"shared","views":2,"presenter":"DP-1",...}open, close and toggle return nothing; the rest echo the state they moved to.
Omarchy's shell-level dispatcher also toggles any plugin, and works equally well for a keybinding:
omarchy-shell shell toggle io.github.elevate08.qs-bitwarden-cliOnly toggle exists at that level, though -- omarchy-shell shell open|close <id> answers Function not found, and omarchy-shell shell call <id> <method> '{}' answers unknown. Use the plugin-target form above for everything other than toggling.
The same calls work through Quickshell directly, which is useful when omarchy-shell is not on PATH:
qs -p /usr/share/omarchy/shell/shell.qml ipc call io.github.elevate08.qs-bitwarden-cli statusThe helper's crates are updated by Dependabot under versioning-strategy: lockfile-only, so a proposed bump only ever moves agent/Cargo.lock within
the bounds agent/Cargo.toml already allows. Crossing a major is a manual
edit, on purpose: several of the version floors in that manifest exist to keep
one copy of the RustCrypto traits in the graph, and Dependabot raising them
one at a time is what broke the build in PR #11.
The crypto stack moves together or not at all. ssh-key and rsa
re-export the trait generation their callers must match, and agent/src/lib.rs
calls those traits directly -- Verifier::verify, try_sign,
pkcs1v15::SigningKey. Bump one crate without the others and cargo resolves
two versions side by side, at which point the traits stop unifying and
nothing compiles. The coupled set is ssh-key, ssh-encoding,
ed25519-dalek, rsa, signature, sha2/digest, zeroize and
rand_core; Dependabot groups them under crypto for the same reason.
As of 2026-08-31 that upgrade is gated upstream: ssh-key is at 0.7.0-rc.11
and rsa at 0.10.0-rc.18, both still pre-release, and the stable releases
still pin the older generation. When they land, raise every crate in the set
in one commit and expect real source changes, not just a manifest edit.
Nothing will prompt you -- there are no ignore conditions to trip, because
cargo's own semver rules already hold 0.10 back from 0.11.
Every accepted bump, major or not, changes the shipped bytes and so needs the
binary rebuilt in the same change, by hand -- see the needs-binary-rebuild
label:
gh pr checkout <n>
./scripts/build-agent.sh # re-enters the digest-pinned image
git commit -am "deps: rebuild the agent binary" && git pushFor other source changes CI does it: on a pull request into a release branch
from this repository, helper-rebuild.yml rebuilds the helpers in the pinned
image and commits them to the PR branch. It never does so when Cargo.lock,
Cargo.toml or rust-toolchain.toml changed, or for Dependabot or a fork.
--compare-tracked proves the committed bytes are what the committed source
builds; it cannot tell you whether that source is trustworthy, and a malicious
crate builds just as reproducibly as an honest one. Reading the Cargo.lock
diff before you commit the binary is the only check that covers that, which
is why dependency rebuilds stay a human step.
- Features in detail -- every feature and why it works the way it does.
- SSH agent -- setup, verification, threat model.
- Uninstall -- including what to clear before removing the plugin.
- Development -- linting and the test suite.
MIT -- see LICENSE.
Footnotes
-
The CLI creates a login by default; other types need the JSON edited before encoding, as its documentation describes -- "use a command-line JSON processor like jq to change a
.type=attribute to create other item types." ↩ -
This plugin will not. The CLI can encrypt a type-5 item, but generating a key means putting private material somewhere this plugin has deliberately kept it out of. ↩
-
Bitwarden documents SSH keys as generated or imported "using the desktop app, web app, and browser extension", and generation is Ed25519 only. ↩
-
Bitwarden's SSH agent is a desktop-app feature; the CLI does not provide one. ↩
-
All three read TOTP codes --
bw get totpon the CLI. The check here is for the follow-up: Enter copies the password and then replaces it with the live code a few seconds later, so a login and its second factor are one keystroke apart. ↩ -
PIN unlock is documented for "mobile apps, browser extensions, and desktop apps". ↩
-
This plugin verifies through the same PAM stack as the Omarchy lock screen, so it works wherever
omarchy setup security fingerprinthas been run. ↩ -
Biometric unlock is documented for the desktop app, browser extensions and mobile apps -- not the CLI. ↩
-
On Linux the desktop app's biometric unlock goes through a polkit agent rather than a fingerprint reader directly. ↩
-
This plugin asks the key for its
hmac-secreton the registrationomarchy setup security fido2writes, and that secret opens the stored password -- so unlocking needs the key, not only a touch. No Bitwarden client offers FIDO2 unlock, so there is no upstream column to match. ↩ -
The CLI has
bw lock, but no timeout of its own -- a session key stays valid until something locks it. ↩ -
The desktop app offers time passed, on system idle, on system sleep, on system lock and on restart. ↩
-
bw importandbw exporton the CLI; the desktop app has both in its UI. This plugin has neither -- it reads and writes single items, and a vault export is a different kind of operation from the one it is for. ↩ -
A delete here is a delete. Bitwarden keeps deleted items in a trash for 30 days and both official clients can restore from it (
bw restore); this plugin shows no trash and cannot restore. ↩ -
This plugin downloads attachments but cannot add one. The CLI has
bw create attachment --file. ↩ -
This plugin creates text Sends only. Both official clients send files too --
bw send -f <path>. ↩ -
Text, hidden, boolean and linked fields follow the same type model as Bitwarden's browser extension. Secure Notes have no linked native field, so the linked type is offered only for logins, cards and identities. ↩
-
bw confirmandbw device-approvalare CLI features; the desktop app does not do this either, and it is otherwise the web vault's job. Listed because the CLI is genuinely ahead of both here. ↩











