一个用惯命令行的人，被迫每天打开Electron应用复制密码——这种割裂感，就像让赛车手去开自动挡买菜车。

作者最终卸载了Bitwarden官方客户端，改用第三方命令行工具。更意外的是：这个"野路子"方案，体验反而碾压官方。

打开网易新闻 查看精彩图片

被忽视的痛点：状态丢失

Bitwarden官方命令行工具叫bw，设计上是"无状态"（stateless）的。每次关闭终端再打开，或者新开一个标签页，调用bw都要重新输入主密码。

作者试过用shell别名自动导出会话密钥，能省一步，但密码还是要输。

更致命的是速度。执行bw get password [name]，经常要等2-3秒才有响应，有时甚至更久。对命令行用户来说，这种延迟足以打断心流。

rbw的解法：后台代理+内存驻留

rbw是用Rust写的非官方Bitwarden客户端。它借鉴了ssh-agent的思路：运行一个后台代理，解锁后把解密的保险库密钥保存在内存里。

操作变成一次性：执行rbw unlock输入主密码，之后所有rbw命令都是即时响应。代理在后台静默处理会话管理，终端关闭、重开、多标签切换都不受影响。

配合fzf（模糊搜索工具）后，找密码的流程变成：敲几个字符模糊匹配、回车、密码进剪贴板。全程不用离开终端，不用等加载动画。

为什么官方不做这个？

Bitwarden的商业模式决定了优先级。GUI应用服务的是主流用户，命令行工具只是"有就行"的配套。安全架构上，无状态设计也减少了密钥泄漏风险——虽然牺牲了便利。

rbw作为社区项目，没有这些包袱。它赌的是：愿意用命令行管理密码的人，有能力评估并接受"内存驻留密钥"的风险模型。

这个赌局的数据在GitHub上：rbw至今保持活跃维护，Issue响应速度比很多官方CLI还快。

关键数据

作者实测的延迟对比：官方CLI 2-3秒 vs rbw即时响应；解锁频率：每次会话 vs 每天一次。对每天调用密码几十次的用户，时间节省累积可观。

更隐蔽的收益是上下文保持。开发工作流不中断，不用从代码编辑器切到密码应用再切回来——这种切换成本，量化很难，但感受真切。