bitwarden-vault

This skill sets up and uses the bitwarden command line client to fetch passwords, secure notes, and other secrets from a vault. It covers three authentication paths: email and password, an api key for automation, and single sign-on. The important requirement is process persistence. After unlocking, a session key is exposed as an environment variable and every later vault command depends on it, so the skill insists on running inside a dedicated terminal multiplexer session that preserves that variable. That means the multiplexer must be installed and managed, and an api key login still needs a separate unlock step, so unattended secret access is not what this provides.

Use case: pulling a stored credential into an automated workflow

The Bitwarden command line client reads secrets out of a vault, but every vault operation after authentication needs the session key that the client prints at unlock time. That is why the documented workflow parks the client inside a dedicated terminal multiplexer session: the exported variable has to survive between one command and the next. ## What it does - Installs through a package manager and exposes the bw binary. - Supports email and password login, a key based login, and a single sign on flow for organization accounts. - Treats logging in and unlocking as separate steps for the non interactive paths. - Reads individual items and lists vault contents once a session is live. - Keeps the session key in an exported variable so later commands in the same session succeed. ## When it is the wrong choice It is a thin wrapper around an interactive login, so it is a poor fit for a one shot non interactive context where nothing is available to answer a password prompt. The multiplexer requirement is not decoration: without a session that keeps the exported key, later commands fail even though authentication itself succeeded. Vault reads also depend on a remote service and a working network path to it, so an offline machine gets nothing back. Finally, the key based login path still needs a separate unlock step, which surprises anyone expecting a single non interactive command to open the vault. ```bash tmux new-session -d -s bw-session bw login bw unlock bw get item github ``` ## Working notes - The session name is arbitrary, and keeping one dedicated name makes the workflow repeatable. - Item reads and vault listings are the common calls once the session is unlocked. - Every vault command after unlock is expected to run inside that same session.