---
title: "Making 1Password browser extensions talk to the Flatpak desktop app"
date: 2026-04-25
tags: [linux, flatpak, 1password, bazzite, browsers, troubleshooting]
summary: Browser extension can't see a Flatpak 1Password desktop app via native messaging. Sandbox isolation is the cause. Fix is the explicit cross-sandbox bridge 1Password ships.
aliases: [flatpak-1password, flatpak-1password-browser-bridge, 1password-host-bridge]
---

If you install the [1Password desktop app](https://1password.com/downloads/linux/) as a Flatpak (the recommended path on [[bazzite-overview|Bazzite]] and other immutable distros), and your browser is also a Flatpak, "Connect to 1Password" hangs. The unlock screen sits forever, or the extension claims the desktop app isn't running even though it clearly is.

Sandboxing problem, not a 1Password bug.

## Why it breaks

The desktop app and the extension talk via [native messaging](https://developer.chrome.com/docs/extensions/develop/concepts/native-messaging). The browser launches a small helper binary (`com.1password.1password.json` on Linux) that opens a Unix socket inside the desktop app's runtime directory. Normal install: both sides share `/run/user/<uid>/`, they find each other.

Under Flatpak, each app runs in its own sandbox. The browser sandbox can't see 1Password's `/run/user/<uid>/` by default. Even if it could, the `NativeMessagingHosts` manifest path the browser scans (`~/.config/<browser>/NativeMessagingHosts/`) is rewritten by the sandbox to a Flatpak-private location.

Net result: browser never sees the manifest, never spawns the helper, never finds the socket.

## Fix

1Password ships a cross-sandbox bridge. Set it up once:

```bash
# Make the manifest visible to Flatpak browsers
mkdir -p ~/.var/app/<browser-app-id>/config/<browser>/NativeMessagingHosts
flatpak run --command=/app/bin/1password-cli com.1password.1Password --setup-browser
```

Typical setup (Vivaldi or Chromium as Flatpak, 1Password as Flatpak):

```bash
# Allow the 1Password app to talk to host browsers
flatpak override --user --talk-name=com.1password.1Password com.vivaldi.Vivaldi
flatpak override --user --talk-name=com.1password.1Password org.chromium.Chromium
```

Then enable **Browser Integration** inside the desktop app: *Settings → Developer → Allow connection from browser extensions*. The integration check inside the extension's settings should now flip to green.

## When it still doesn't work

- **Wayland-only browsers.** A few extensions misbehave under pure Wayland. `--ozone-platform-hint=auto` in the browser launch flags often fixes it. For Vivaldi specifically, [[vivaldi-persistent-flags]] is where the flag belongs.
- **App ID mismatch.** 1Password 8 uses `com.1password.1Password`. The 7.x snap manifest used `com.onepassword.OnePassword`. Mixing the two silently fails. Check `flatpak list | grep -i password`.
- **`com.1password.1Password.Policy` missing.** Happens if you grabbed the app from a third-party Flathub mirror without the `Policy` extension. Reinstall from the official Flathub remote.
- **PIN/biometrics on the wrong account.** Only one signed-in account at a time can serve native messaging. Switch primary account in *Settings → Accounts*.

## Related

- [[bazzite-overview]]. Why Flatpak is the default install path on immutable Fedora.
- [[rpm-ostree-rebase-cheatsheet]]. If reinstalling 1Password meant a base image change.

## References

- [1Password — native messaging](https://developer.1password.com/docs/cli/native-messaging/)
- [Flatpak sandbox permissions](https://docs.flatpak.org/en/latest/sandbox-permissions.html)