KeePassXC-Browser: filling passwords from a local vault

What actually connects the two halves

A browser extension cannot open a file, call into a Qt desktop application or talk to a process directly, so the interesting question in any password manager extension is what bridges the gap. Here the answer is keepassxc-proxy, and the README is unusually clear about how it behaves.

The proxy handles listening to STDIN and STDOUT and transfers those messages through Unix domain sockets on Linux and macOS, or named pipes on Windows, to the KeePassXC process. From the browser's point of view it is an ordinary native messaging host. From KeePassXC's point of view it is a client like any other.

The consequence is stated in the README plainly: KeePassXC can be used and started normally, without interference from the native messaging API. The extension starts only the proxy, so there is no risk of shutting down KeePassXC or losing unsaved changes. That is a real design constraint that many competing extensions fail, because the alternative is a helper process that owns the application lifecycle.

You do not need to install the proxy separately. It ships inside the KeePassXC application package. If you would rather avoid Qt entirely, keepassxc-proxy-rust is a separate implementation you can point the extension at instead.

The permission list, read carefully

Password manager extensions ask for a lot, and the only useful response is to read the reasons rather than count the entries. The README includes a table with a reason column, and most of the wide access turns out to be load-bearing.

Both `http://*/*` and `https://*/*` are requested so the extension can work on all websites, which is unsurprising for a password manager and also the reason to install it from the official store rather than sideloaded. `cookies` is requested to access the browser's internal Public Suffix List, which is how it decides whether a domain is safe to offer credentials for. `activeTab` and `tabs` cover reading the current URL and tab information so it knows where it is.

The cluster around `webRequest`, `webRequestBlocking` and `webRequestAuthProvider` is all for HTTP Basic Auth. This is the part most extensions quietly omit, and without it the extension cannot fill a username and password into a native authentication dialog that the page never rendered. `clipboardWrite` exists so a password generated in the vault can go straight to the clipboard.

Two entries are worth a second look rather than a second glance. The `storage` permission is used for extension settings, and the README states these are always stored locally in the browser and are never synced, so your extension preferences do not travel with your browser profile to Google or Mozilla. The narrow `https://api.github.com/` scope exists only to check the latest KeePassXC version from GitHub.

So the request looks like broad access, but it decomposes into site matching, domain validation, Basic Auth, clipboard, notifications, the proxy channel, and a version check. There is no line here that sends your vault anywhere.

Passkeys are where the work is now

Release 1.10.4, published 2026-09-16, is dominated by passkey work, and the shape of that list is informative. There are two feature lines among the fixes: support for the PRF extension, and support for cross-origin iframes together with permission policy. Everything else is correction, including unhandled callbacks, wrong return types, null checks on passkey responses, and using an abort signal where one is available.

That ratio is what an implementation looks like while it is being used against real sites. WebAuthn has a lot of variation between browsers and embedding contexts, and a passkey flow that breaks on one site is not a fixed by adding a feature. The cross-origin iframe line in particular is about the credential request happening in a frame the extension does not own.

The same release also carries a batch of ordinary autofill corrections that describe real sites: Reddit problems, an Apple School page field, a Fastmail login page, an Atlassian page in the previous release, and fixes around placeholders, readonly username fields and context menu messages going to the current frame only. It also adds a keyboard shortcut for locking the database, and refactors credential saving.

The version before it, 1.10.3 from 2026-06-01, added a WebSocket connection method that is explicitly disabled until KeePassXC supports it. That is the pattern to read carefully in a project like this: features can land ahead of the backend they need, and the flag on the feature is the honest part.

The repository is a build pipeline

The default branch is `develop`, which tells you the published extensions are built from a branch that is not what most people open. The tree explains the pipeline: `dist/` holds the per-browser manifests, `build.js` is the entry point, `keepassxc-browser/` is the extension source, and `tests/` plus `playwright.config.ts` are the test setup. Translations live on Transifex with a `.tx/` directory, and a `CHANGELOG` file sits at the root.

The manifest makes the loop explicit, and it is worth reading because it explains how someone develops against two different browser targets at once.

  "scripts": {
    "build": "node build.js",
    "debug:chromium": "cp dist/manifest_chromium.json keepassxc-browser/manifest.json",
    "debug:firefox": "cp dist/manifest_firefox.json keepassxc-browser/manifest.json",
    "lint": "npx eslint --no-warn-ignored keepassxc-browser/**/*.js",
    "tests": "npx playwright test"
  },

Debugging a WebExtension locally means pointing the manifest at a real directory, so the two debug scripts copy the Chromium or Firefox manifest over the working one. Tests run through Playwright, and linting is ESLint 9 with flat config, which matches an `eslint.config.mjs` at the root. The extension is GPL-3.0, authored by the KeePassXC Team, and first shipped support in KeePassXC 2.3.0 at the end of 2017.

The messaging protocol itself is documented in `keepassxc-protocol.md` in the repository, which is the file to read if you want to know what the proxy is actually being asked for.

Where it fits, and what to watch

Availability is broad. The extension is published for Firefox through addons.mozilla.org, for Chrome and Chromium through the Chrome Web Store, and for Microsoft Edge through the Edge add-ons store. The README advises using the latest available release generally, which is the right instinct for an extension whose permissions and page-detection logic change with the sites it must work against.

The connection setup is not automatic. The README points to KeePassXC's browser integration documentation for instructions on configuring the application to accept the database connection, and there is a separate troubleshooting guide in the project wiki for when the obvious fixes have not worked. Both pointers matter more than they might in another project, because the failure modes here are all at the boundary between two applications and one browser, and each of the three can be the thing that is misconfigured.

On maintenance signals: the last push was 2026-09-28, days before release 1.10.4, so the branch is where development happens. 203 open issues against 2,343 stars is high in absolute terms and normal for a project that a large population installs and reports from. Forks number 248, which is where the hand-off work for a project like this tends to live.

If you are evaluating this against a browser's built-in password manager, the honest comparison is not features but custody. This extension is for people who want their vault as a file on their own disk, backed up how they choose, with the browser acting as a client to a local application rather than as the place the passwords live.

Editorial conclusion

The design decision that makes KeePassXC-Browser worth trusting is the proxy. The extension never links against the application and never needs it running in a particular state; it starts keepassxc-proxy, which forwards native messaging traffic over a Unix socket or a named pipe, and nothing else. That is why unlocking, saving and passkey operations all work without the extension being able to shut down KeePassXC and lose an edit in progress. Two things to keep in mind. Version coupling is real, so use the latest release of both sides and read the connection instructions for your platform. And the permission list is wide, covering every URL, cookies and webRequest for Basic Auth, which is exactly what a password manager needs and exactly what you should read before trusting any extension in this category. On passkeys the recent releases have been mostly fixes rather than features, which tells you the implementation is still settling.

Frequently asked questions

Official sources

1. Issues
2. keepassxreboot/keepassxc-browser on GitHub
3. License: GPL-3.0
4. README
5. Releases