Typing was impossible — each character vanished, and pasting flashed and
reverted to the saved value.
`useClient()` calls `createClient()` on every render with no memoisation, so
`get`/`put` are new function identities each time. The panel wrapped its
fetches in `useCallback(..., [get])`, which therefore also changed identity
every render, and the effects depended on THOSE:
keystroke -> setUrl -> re-render -> new `get` -> new callback -> effect fires
-> GET /config -> setUrl(saved value) -> character gone
Fixed by making them plain functions and loading once on mount, with the health
probe fired from the load rather than from a second effect watching
`configured` — an effect is one more thing that can re-fire.
The rule, written into the file since nothing about the symptom pointed at a
dependency array: never put a value derived from `useClient()` in a dependency
array. The rest of the codebase already follows it (CommandHqDetail keys its
fetch effect on `sessionId` alone).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Vault
Your passwords, in a Vaultwarden you already run, reached through Officer.
Vault does not store passwords and cannot read them. It is two things: a reverse-proxy to a Vaultwarden server you point it at, and a credential broker that keeps the vault session on the server so your devices never have to hold one. The vault is end-to-end encrypted — every byte through here is ciphertext, and nothing in this plugin decrypts, parses, caches or logs a request body.
What you get
- One address for everything. Officer's own mobile app signs in to Officer and reaches the vault at
/api/vault— it never sees a Vaultwarden token, because the server holds it and injects it on the way through. - A session that follows your Officer session. Sign out and the brokered vault session goes with it. Hit distress or panic and the stored unlock key goes too, so the next unlock needs the master password — which is the whole point of those buttons.
- A settings screen at
/vault: paste the URL of your Vaultwarden, see whether it answers, turn the proxy off without forgetting where it lives.
What you need
A Vaultwarden you already run. This plugin does not install one, provision a container, or manage anything about it — you give it a URL and it forwards there. It is equally happy with one on the same machine, one on your tailnet, or one behind a reverse proxy somewhere else.
Nothing else. No system packages, no host binaries.
Setup
- Install the plugin.
- Open /vault and enter your Vaultwarden's address, e.g.
https://vault.example.com. - Press Check. A green "Answering" means Officer can reach it.
Changing the URL later takes effect within about ten seconds — the sidecar re-reads it on a short timer, so there is nothing to restart.
What it deliberately does not do yet
Stated plainly, because a store listing that only says what works is an advertisement.
- There is no password list, and there will not be one here. Reading vault items needs the decryption keys, which live on your devices. Use a Bitwarden client or Officer's mobile app.
- Third-party Bitwarden clients cannot point at Officer. The browser extension used to be able to, through an unauthenticated passthrough at Officer's own hostname. That path could not come with the plugin: a plugin's routes mount behind Officer's account gate, and top-level unauthenticated routes are not something a plugin can declare. Point Bitwarden clients at your Vaultwarden directly for now. The intended replacement is a first-party browser extension that authenticates to Officer like every other client, which removes the need rather than restoring the workaround.
- Push notifications fall back to polling. Vaultwarden's live "your vault changed" socket is not proxied — no plugin owns a websocket yet on this platform. SignalR degrades to HTTP long-polling on its own, so clients still sync; they learn about changes on their next poll rather than instantly.
- One Vaultwarden per install, and it is the owner's. The URL is server-wide and every route is owner-only. Mapping additional Officer accounts onto Vaultwarden's own users is a real feature and is not built.
- Uninstalling keeps your data. The tables survive, as they do for every plugin — only deleting the plugin's source drops them. Your Vaultwarden is untouched either way; this plugin never wrote to it.