Description of the issue:
Brave Browser keeps losing all saved logins and cookies whenever I switch between different Linux desktop environments (Hyprland, GNOME, KDE).
Even if the browser starts correctly and keyrings are supposedly working, Brave behaves as if it’s a fresh install: all sessions are gone, I’m logged out everywhere.
My Setup :
Brave version: brave-bin from AUR (Brave Browser 138.1.80.124)
OS: Arch Linux
DEs tested: GNOME, KDE Plasma, Hyprland
Keyrings:
GNOME: gnome-keyring-daemon running, started via SDDM
KDE: kwallet active and configured
Hyprland: tried both keyrings, added gnome-keyring-daemon startup manually
Login Method: Mostly using SDDM, sometimes direct Hyprland launch
at this point that’s a ll what i tried to do :
Verified gnome-keyring-daemon is running in GNOME:
kwalletmanager shows Brave keys(1) under both Default keyring and KDEwallet
The safe storage keys differ between them:
Y5ly/qpV10SqVNu3d9Q58g==
jvmIGWK1nnE8QmmfTBC1dg==
In Hyprland:
Tried launching gnome-keyring-daemon manually
Also configured PAM and exported env vars
Still no luck, logins are always gone
In GNOME:
I do get prompted to unlock the keyring
But logins are still lost, even though gnome-keyring is running
XDG Desktop Portal shows Brave registered with strange binary data in GNOME when using KDEwallet
I tried launching Brave with brave --password-store=basic,
That does persist logins, but obviously it’s not secure and skips encryption, which defeats the purpose of having a keyring at all.
What I Think Is wrong:
Brave is pulling different “safe storage” keys from different keyrings (GNOME vs KDE), so encrypted cookie/login data becomes undecryptable when switching DEs. And in Hyprland, sometimes the keyring isn’t started or unlocked properly, which causes complete loss of session state, please inform me if i am wrong ?.
I’d really appreciate help from anyone who;
Can confirm how Brave manages keyring access across DEs
Knows how to force Brave to use a single, consistent keyring across GNOME, KDE, and Hyprland
Or can suggest a way to preserve login data between sessions without going fully unencrypted
Thanks in advance I’m honestly out of ideas at this point.
Changing between desktop environments that don’t default to the same password store backend (e.g. switching from GNOME to KDE) without letting Chromium know about it (via --password-store=gnome-libsecret in this example).
I think I understand now the issue,it comes from switching between desktop environments (like GNOME to KDE) where Brave ends up using a different keyring backend (like libsecret vs kwallet), which causes it to “forget” the saved data.
I originally started Brave under KDE, and sometimes i switch DE’s , so that explains the behavior.
If I understand correctly, I can fix this by forcing Brave to use the same password backend using the --password-store=... flag?
For example:
brave-browser --password-store=kwallet
or
brave-browser --password-store=gnome-libsecret
Is that the recommended way to handle this if I switch between DEs? Or is it better to stick with one DE to avoid Brave getting confused?
Also, should I update the .desktop launcher to make this change persistent?
@saber26 I think you’re right in the example. I have never used Linux a day in my life and am very limited in my understanding of it. Not sure if it’s much of a help but I did feed info into ChatGPT along with its own knowledge, to which I asked it to give a final answer for you. If it’s still questionable or you have issues, we’ll tag Mattches or get someone more knowledgeable in.
You’re exactly right. The issue comes from switching desktop environments that use different password storage backends, like GNOME (libsecret) and KDE (KWallet). When Brave is not told explicitly which one to use, it cannot find the original encryption key and ends up acting like it “forgot” your saved data.
To fix it, yes, using the --password-store= flag is the way to go. If you originally ran Brave under KDE, then:
brave-browser --password-store=kwallet
is the right one to use, even if you switch to GNOME later. This tells Brave to always look in the same place for the encryption key, no matter which desktop environment you are using.
To make the change permanent, it is a good idea to edit your .desktop launcher and add that flag to the Exec= line. That way, you do not have to remember it every time you launch Brave.
Sticking to one desktop environment would prevent this issue entirely, but if you like switching between environments, just make sure Brave always uses the same password backend and you should be fine.
Hope that helps. Let me know if you need help updating the launcher or anything else.
Bonus tip: Beware of password overwrites
If Brave is run without the correct password store and creates new saved passwords, it might start using a different keyring and begin saving new entries separately. This can cause further confusion.
To avoid that:
Always verify the password store backend before entering new passwords.
And somewhere I recently read, that the keyring must be unlocked before launching the browser. Maybe here ← " The Keyring Concept in Ubuntu: What is It and How to Use it?"
sadly, I tried launching Brave on GNOME using this:
brave-browser --password-store=kwallet
But I get multiple kwalletd DBus errors like:
Failed to call method: org.kde.KWallet.isEnabled
Error contacting klauncher to start kwalletd
So clearly kwalletd isn’t accessible under GNOME which makes sense and expected since kwallet is not running.
Then I switched to KDE and ran Brave with:
brave-browser --password-store=kwallet
No errors this time, but still can’t sign into Google ,I get this error:
This browser or app may not be secure. Try using a different browser…
This happens on both KDE and GNOME regardless of the --password-store flag, even when the keyring appears to be working.
At this point, even setting the password store manually doesn’t solve the issue. Could this be tied to user agent / missing OAuth token storage? Is Brave still blocking certain login flows on Linux if the keyring isn’t set up “perfectly”?
Would love any advice or workaround you know of , I just want to keep my sessions stable and be able to log into sites like Google again.
the keyring will be unlocked after the password prompt, however, even if we are in KDE and it’s unlocked, the error This browser or app may not be secure. Try using a different browser… in google is still there when launching with brave-browser --password-store=kwallet , this ain’t happening in kde nor gnome when launching brave’s default
Thanks a lot for the help and the links @289wk and @Saoiray (again), they really pointed me in the right direction. It turns out the issue comes from Brave (Chromium) relying on different keyring backends depending on the desktop environment ,libsecret for GNOME and KWallet for KDE. If you switch DEs or don’t unlock the expected keyring, Brave can’t access stored passwords or sessions properly. To fix this, I decided to stick with GNOME Keyring even on KDE. First, I opened KWalletManager and disabled the “Use KWallet for storing secret service data” option under its settings. Then I created a .desktop file at ~/.config/autostart/gnome-keyring-daemon.desktop to autostart GNOME Keyring in KDE. In that file, I set the command to gnome-keyring-daemon --foreground --components=pkcs11,secrets --control-directory=/run/user/1000/keyring/. I also edited the Brave launcher (or .desktop entry) to include --password-store=gnome-libsecret(optional , just in case). Now Brave consistently uses GNOME Keyring across both GNOME and KDE without losing login sessions or throwing password storage errors. Hopefully this helps others who hit the same problem when switching between desktop environments.
Bonus tip: Beware of password overwrites