Problem

If KeePassXC is sandboxed in a Flatpak, browsers can only access it, if they are not sandboxed, i.e. installed as an deb/rpm package or similar on the host.
Sandboxing both the browser, i.e. Firefox, and KeePassXC – or at least the browser and installing KeePassXC natively, which you’d actually want for security reasons – is not possible.

TL;DR:

this should work out-of-the box: Firefox (host-installed), KeePassXC (flatpak from flathub)

this does not: Firefox (sandboxed), KeePassXC (host or sandboxed, does not matter)

I show a workaround that makes it possible to use both configurations.

Background

If you just want the solution, you can skip this part. But for the curious, I’ll explain the problems we face:

KeePassXC creates an UNIX socket in $XDG_RUNTIME_DIR/kpxc_server for applications to listen too. keepassxc-proxy is started – via native messaging – by the browser (triggered by the add-on keepassxc-browser@keepassxc.org, i.e. KeePassXC-Browser) and tries to listen on that socket to find messages.

If Firefox is not sandboxed, that proxy can start as usual. The only thing it possibly needs to do is get into the KeePassXC flatpak.

Flathub KeePassXC has a patch that allows the keepassxc-proxy to be started via flatpak run, i.e. Firefox can now run a

So we could solve that by making wrapper scripts and using flatpak-spawn to let Firefox escape it’s sandbox. However, seeing how lovely and quite securley the Firefox sandbox is already built, I would not dare to destroy that security for such a feature. After all, from a security POV you could then also just install Firefox on the host, yet again.
So glad news ahead: This solution preserves all sandboxes and security aspects!

However, even if we’ve solved the fact of Firefox having to run the proxy, there are more problems. To spoiler, this are the main points we need to solve:

Starting keepassxc-proxy by Firefox (solution: we run it inside the Firefox sandbox)

Allowing Firefox to access the socket of KeePassXC
Note: At that step, you can already run the variation: Firefox (sandboxed), KeePassXC (host-installed)

Exposing the UNUX socket from the KeePassXC flatpak to other applications outside of the Flatpak. (solution: an symbolic link)

Current workaround

Starting keepassxc-proxy by Firefox

Worst things first: We need the keepassxc-proxy as a binary, because we want to have it run inside of the Firefox flatpak. Good for us: it has not many depenencies and is available as a stand-alone application.

So I chose the Rust proxy application (because why should not I? ). If you trust me, you can get my compiled binary below, just skip to two steps ahead.

Note that only absolute paths work (I guess), so replace REPLACE_WITH_USERNAME with your $USER name, so that the paths leads to it’s own working dir.

You see what I am doing: We now place the downloaded/compiled keepassxc-proxyin the same dir. Obviously, you could use any other path there, but this was the first one that is obviously accessible by Firefox and you have everything in one place. (If you have better suggestions, feel free to let me know.)Note: Remember to make it executable (chmod +x) if it is not, already.

Allowing Firefox to access the socket

KeePassXC, by default, creates it’s socket in $XDG_RUNTIME_DIR/kpxc_server. So this is what we need to give the Firefox flatpak access to (read-only is obviously enough).

Hooray!: For those, who install KeePassXC on the host (without any sandbox/flatpak), this is enough. Start KeePassXC and then Firefox and it should be able to connect.
Please note the “existing problems” section at the bottom, though.

Continue, if you also want to run KeePassXC in a flatpak.

Exposing the UNIX socket from the KeePassXC flatpak

Note: Again skip to the bullet point (point 1) below, if you don’t wanna know the technical background.

The flatpaked KeePassXC from Flathub creates it’s Unix socket in the location flatpaks should do so, in $XDG_RUNTIME_DIR/app/org.keepassxc.KeePassXC/kpxc_server. (If it would use $XDG_RUNTIME_DIR directly like the “native” KeePassXC, it would only exist in the sandbox.)

As we know, the usual keepassxc-proxy expects the file at $XDG_RUNTIME_DIR/kpxc_server. To solve this, we just create a symbolic link.
As you can verify, this actually solves our problem. For some very strange reason, the Flatpak sandbox now allows Firefox (and all other flatpaks! Just FYI, be aware of that.) to see that UNIX socket file.
As it should turn out later, this does not work when you move that symbolic link anywhere else (even another file name already prevents it from working – I’ve tried a lot of things.).

However, $XDG_RUNTIME_DIR is usually deleted at shutdown. So we need to recreate it at startup/user login. Good for us there, is already a tool for that. (you could also mangle with shell scripts in your autostart of course, but that is ugly.)
That’s why we make use of systemd-tmpfiles. (The man page for tmpfiles.d is more useful for us actually.)

Go to ~/.local/share/user-tmpfiles.d. Again, there is a high chance the user-tmpfiles.d dir does not exist yet. If so… well… you know what to do…

Now download and place the following config file in there: kpxc_server.conf
This is basically a config file for systemd-tmpfiles that says it to create that symbolic link for the user.

Reboot, so systemd-tmpfiles can apply the changes and create the config file.

Hooray!: Afterwards start the KeePassXC flatpak and then Firefox and it should be able to connect.

Please note the “existing problems” section below.

Existing problems

Firefox, for some reason, cannot see the $XDG_RUNTIME_DIR/kpxc_server file, if the file (respectively it’s symbolic link target) does not exist yet.
In practise, this results in one big disadvantage: You always need to start KeePassXC before Firefox.

For some more strange reason, if you have this workaround setup, the usual way that you run a non-flatpaked native Firefox and connect it by spawning the proxy inside the flatpak (like flatpak run org.keepassxc.KeePassXC) may not work. Delete the symbolic link again to make this work.

Debugging tips

In Firefox use about:debugging to access add-on internals. keepassxc-browser@keepassxc.org is the add-on ID. It actually also logs failed attempts. Note there are different results (logs and visibly) when it cannot start the proxy vs when it can start the proxy, but no connection suceeds (because the UNIX socket is not there, e.g.)

To manually get into the flatpak and “see” in a shell what it has access to/looks like, use something like flatpak run --command=/bin/sh org.mozilla.firefox.

To check whether the socket file is accessible (a symbolic link can point to a non-existant file) just cat it and you’ll see a strange error that cat cannot find a resource

Things I’ve tried

Things that do not work:Preserved for future solutions and better™ workarounds.

all things in $XDG_RUNTIME_DIR/app are highly sandboxed, even with flatpak overrides I could not get the Firefox flatpak to read the content of the ../org.keepassxc.KeePassXC dir. Even with crazy symbolic links in it’s own dir. (Do try it though, maybe you’ll make it! At least you’ll learn something. .)

what works though is: You can override the KeePassXC flatpak to get access to Mozilla. Only write access possible though! Thus, if it would place the proxy there (again: symbolic links here don’t work!), Firefox could also read it.

The symbolic link must be created by an application outside of the sandbox. Inside of it, it’s again – sandboxed – and one only visible inside of it.

I haven’t had a chance to digest all of this yet, but besides all the GitHub links it is probably worth referencing this ticket in Mozilla’s bug tracker for the Firefox Flatpak regarding support for KeePassXC and other extensions that use native messaging. Also, perhaps you want to provide a reference for your solution on that ticket.