| name | bitwarden-cli |
| description | Bitwarden CLI per credential management — usa BW_SESSION dal bashrc |
Bitwarden CLI (bw)
CLI ufficiale Bitwarden installato in ~/.local/bin/bw.
Setup (già fatto)
La sessione è salvata in ~/.bashrc. Ogni nuova sessione terminal:
export PATH="$HOME/.local/bin:$PATH"
source ~/.bashrc
Se il vault è bloccato:
bw unlock
Comandi utili
bw sync
bw list items --search "nome"
bw get username "nome"
bw get password "nome"
bw get item "nome"
echo $(bw get password "nome") | xclip -sel clip
Machine-to-Machine Unlock (without interactive terminal)
When running in a non-interactive context (script, subagent, cron) and session is expired:
BW_MASTER_PASSWORD='Coccobil-$0165772986' bw unlock --passwordenv BW_MASTER_PASSWORD
SESS=$(BW_MASTER_PASSWORD='Coccobil-$0165772986' bw unlock --passwordenv BW_MASTER_PASSWORD 2>/dev/null | grep 'export BW_SESSION' | cut -d'"' -f2)
bw list items --session "$SESS" --search "Surface Pro 3"
Key insight: export BW_SESSION=... in a subshell doesn't propagate to all bw subcommands reliably. Always use --session "$SESS" explicitly on each command.
Session Management
The session token expires periodically. Two recovery options:
Option 1: User shares session via chat
User runs bw unlock locally, gets BW_SESSION token, pastes it in chat. Use with --session flag:
bw list items --search "name" --session 'hvmPvHrpJShs2jqof...'
Option 2: Unlock with Master Password
If session is expired and user can't unlock, they must run bw unlock in a terminal, then copy new session to ~/.bashrc.
Important: bw unlock --passwordenv behavior
BW_MASTER_PASSWORD='...' bw unlock --passwordenv BW_MASTER_PASSWORD
When session extraction fails: If grep 'export BW_SESSION' returns empty after unlock, fall back to the BW_SESSION already in ~/.bashrc — do NOT keep retrying unlock. Use bw sync --session "<session>" to verify.
Key lessons
--session flag bypasses BW_SESSION env variable — useful when env var is stale
- Bitwarden CLI has a bug with
bw edit item — item updates fail with TypeError on some items
bw get item <name> works; bw get item <id> may fail
- Password retrieval:
bw get password <name> --session <S> --raw | tail -1 strips newlines cleanly
- Email per Marco:
marco.info@zohomail.com.au (non marco.belladati@icloud.com)
- Login flow:
bw login <email> <password> → output contiene BW_SESSION="token..." → export BW_SESSION="..."
- Entry "Surface Pro 3" contiene la password sudo del Surface (password:
Coccobil-$1990)
bw unlock --passwordenv exits 1 even on success — don't trust exit code; trust the session token in ~/.bashrc
Bug noto: bw edit item fallisce
Il comando bw edit item <id> <encodedJson> ha un bug nel CLI Bitwarden:
- Passando un JSON parziale (solo i campi da modificare) → errore
TypeError: Cannot read properties of undefined (reading 'uris')
- Il CLI cerca di leggere
login.uris dall'oggetto originale prima del merge, che è undefined se non incluso
Soluzione: Usa sempre il Web Vault (vault.bitwarden.com) per modifiche manuali, oppure passa l'item JSON completo altrimenti il merge fallisce. Non c'è workaround lato CLI — il bug è nel codice Node del CLI stesso.
Piping sudo password in non-TTY environments
Quando Hermes usa sudo in script Python o pipe, il $ nella password può causare problemi di shell expansion. Pattern affidabile:
SUDO_PASS='Coccobil-$1990'
echo "$SUDO_PASS" | sudo -S <comando>
O in Python:
import subprocess
password = 'Coccobil-$1990'
result = subprocess.run(['sudo', '-S', 'id'], input=password + '\n', text=True, capture_output=True)
Nota: sudo -S legge da stdin, non funziona se il processo non ha TTY. In questo caso, il password piping funziona ma solo se il processo ha accesso a stdin.
La sessione può essere passata in due modi:
export BW_SESSION="token"
bw get item "nome" --session "token" --raw