Repository navigation
safeStorage unavailable on Linux breaks login persistence and connection catalog #5427
Description
Summary
On Linux (GNOME/Wayland), safeStorage.isEncryptionAvailable() returns false even when the Secret Service is running and the default keyring collection is unlocked. This breaks two things:
-
Login never completes / session not persisted. Clerk's Electron storage adapter (
@clerk/electron/storage) refuses to persist session tokens when OS encryption is unavailable andunencryptedFallbackis not enabled. Log shows:Clerk: OS encryption is unavailable and unencryptedFallback is not enabled, so tokens are not being persisted. The user will be signed out on the next launch.Result: Google OAuth login via the
t3code://deep link never sticks — the user is bounced back to the sign-in screen. -
Cannot register connections. The desktop connection catalog store (
DesktopConnectionCatalogStore) requiressafeStorage; when unavailable,setreturnsfalse:Could not register connection: ConnectionTransientError: Could not save the local connection catalog: Desktop secure storage is unavailable in this system context.
Environment
- Linux (GNOME, Wayland), Electron 41.5.0 (packaged AppImage-style build at
/opt/t3code-bin) gnome-keyring-daemonrunning (--daemonize --login+--start --foreground --components=secrets)org.freedesktop.secretsowned on the session bus, default collection/org/freedesktop/secrets/collection/loginunlocked (Locked = false)secret-tool store/secret-tool lookupsucceed from the same user sessionsafeStorage.getSelectedStorageBackend()reportsbasic_text(i.e. Chromium's key-store detection fell back to plaintext despite a working keyring)
Suggested fix
-
Clerk storage — in
createDesktopClerkBridge(apps/desktop/dist-electron/main.cjs), passunencryptedFallback: trueto the storage adapter:storage: storage({ path: stateDir, unencryptedFallback: true })
This makes tokens persist (unencrypted) when OS encryption is unavailable instead of silently dropping them.
-
Connection catalog — make
DesktopConnectionCatalogStorefall back to plaintext whensafeStorage.isEncryptionAvailable()is false (e.g. store arawCatalogfield alongsideencryptedCatalog), instead of returningfalsefromset. -
Root cause — worth investigating why Chromium's key-store detection returns
basic_texton Linux with a working, unlocked Secret Service (DBus connection toorg.freedesktop.secretssucceeds from the app process). This may be an Electron/Chromium issue affecting all Linux users with certain keyring setups.
Workaround (until fixed)
Patch the packaged app: enable unencryptedFallback for Clerk storage and plaintext fallback for the connection catalog. Happy to share the exact patch.
Activity
Xyz3R commentedon Aug 10, 2026
I encountered this on Fedora with niri. Although a working keyring was installed, Electron selected:
This makes safeStorage.isEncryptionAvailable() return false, so Clerk refuses to persist tokens.
Root cause
Electron/Chromium chooses its Linux password backend based primarily on the detected desktop environment. It does not
reliably discover an available Secret Service provider through D-Bus.
This particularly affects compositors such as niri, Hyprland, and Sway, but it can also happen when a GNOME/KDE
application is launched without the expected desktop environment variables.
Electron then falls back to basic_text, even if org.freedesktop.secrets, GNOME Keyring, or KWallet is working.
Relevant documentation:
Fix
Explicitly select the installed encrypted backend when launching T3 Code.
For GNOME Keyring, KeePassXC Secret Service, or another libsecret provider:
--password-store=gnome-libsecret
For KWallet 6:
--password-store=kwallet6
First, test it from a terminal:
/path/to/T3-Code.AppImage --password-store=gnome-libsecret
Or with KWallet:
/path/to/T3-Code.AppImage --password-store=kwallet6
If login persists after restarting T3 Code, add the flag permanently to its desktop entry. Copy the system entry into your
user application directory if necessary:
mkdir -p ~/.local/share/applications
cp /usr/share/applications/t3code.desktop ~/.local/share/applications/
Then edit the Exec= line in the copied file. For example:
Exec=/opt/t3code-bin/t3code --password-store=gnome-libsecret %U
For an AppImage using KWallet 6:
Exec=/path/to/T3-Code.AppImage --password-store=kwallet6 %U
Refresh the desktop application database:
update-desktop-database ~/.local/share/applications
Fully quit and relaunch T3 Code. The selected backend should now be gnome_libsecret or kwallet6, rather than basic_text.
This fixed the Clerk token persistence for me and fully fixed all login backend functionality.
Project516 commentedon Aug 19, 2026
Hey, got this same issue too. I am on fedora 44 kde.
t3dotgg commentedon Aug 27, 2026
Thanks for the detailed report. We believe this is resolved by selecting
gnome-libsecretor the installed KWallet version as the Linux password-store backend.There is a concrete configuration resolution for the reported basic_text backend despite an available keyring: explicitly select gnome-libsecret or the installed KWallet generation. One commenter confirms that this restores all login backend behavior, and a linked closed report independently confirms the same remedy. Current T3 supports explicit backend selection. This is a support closure, not a claim that automatic detection works on every Linux desktop or that plaintext fallback shipped.
I'm closing this as a configuration or support resolution as part of an automated pass on all open issues. This does not claim that T3 Code shipped a code fix. If new evidence shows that current T3 Code causes the problem, please reply with the version and reproduction details, and we can reopen it.