pastilhasandClaude Opus 5 4006be0e3b claim the root paths back, so the setup is the bare Officer URL again
Before the extraction this worked by pasting https://officer.example.com into a
Bitwarden client and logging in normally. The extraction moved the door to
/api/vault/bw, which needs five URLs configured by hand — technically the same
thing, practically nobody's setup.

Declares what it actually needs, now that the platform can express it:

  unauthenticatedRootPaths  /identity, /notifications, /icons, /events — the
                            four a Bitwarden client derives from a bare server
                            URL. None is a name Officer serves, so the path
                            alone decides and no sniffing is involved.

  protocolHeaders           bitwarden-client-name, bitwarden-client-version,
                            device-type — for /api/*, the one namespace both
                            servers claim, where the path cannot separate
                            Vaultwarden's /api/sync from Officer's /api/chat.

`publicRouter` is exported for the platform to mount above the gate. One router
serves all three doors: it strips /api/vault/bw when reached that way, and
otherwise the path is already Vaultwarden's own.

/bw stays. It costs nothing and remains the explicit address for a client that
would rather be told than infer.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 14:47:20 +00:00

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

  1. Install the plugin.
  2. Open /vault and enter your Vaultwarden's address, e.g. https://vault.example.com.
  3. 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.
S
Description
Vault — your Vaultwarden, behind an Officer session
Readme
2 MiB
Languages
TypeScript 100%