[BUG] Desktop Linux on ChromeOS/Crostini: silent fallback to unencrypted storage — "sign-in won't be saved" despite working gnome-keyring

Same bug outside Crostini — reproduced on Sway/wlroots, which suggests the trigger is broader than ChromeOS.

Environment: claude-desktop 1.24012.9 (official apt), Debian 13 trixie amd64, kernel 7.1.3, sway 1.12 / wlroots 0.20, XDG_CURRENT_DESKTOP=Sway, xdg-desktop-portal 1.20.3, xdp-gtk 1.15.3, xdp-gnome 48.0, gnome-keyring 48.0.

Identical symptom and identical Local State evidence:

{"os_crypt":{"portal":{"prev_desktop":"Sway","prev_init_success":false}}}

gnome-keyring running, org.freedesktop.secrets on the bus, default collection unlocked.

The mechanism here is slightly different from X-Generic defeating DE detection. On a non-GNOME Wayland compositor, xdg-desktop-portal binds no Secret backend at all: only gnome-keyring.portal and kwallet.portal implement org.freedesktop.impl.portal.Secret, and gnome-keyring.portal declares UseIn=gnome. With default=gtk;wlr in portals.conf and no explicit Secret route, the interface has no implementation to route to.

A second workaround, without --password-store: add an explicit route to ~/.config/xdg-desktop-portal/portals.conf

org.freedesktop.impl.portal.Secret=gnome-keyring

then systemctl --user restart xdg-desktop-portal. prev_init_success flips to true and sign-in survives restarts.

I A/B tested this to rule out the portal restart being the actual fix — both arms included an identical restart:

| portals.conf | busctl --user introspect org.freedesktop.portal.Desktop /org/freedesktop/portal/desktop \| grep -c org.freedesktop.portal.Secret |
|---|---|
| no Secret route | 0 |
| org.freedesktop.impl.portal.Secret=gnome-keyring | 1 |

So the explicit route is what binds the backend, and notably it does take effect despite the backend's own UseIn=gnome.

This supports the report's core request from another angle: the portal path can work here, so the silent fallback to unencrypted storage is the defect rather than the portal being genuinely unavailable.

Diagnostic note for anyone reproducing: don't introspect org.freedesktop.impl.portal.Secret to check whether a backend is bound. gnome-keyring.portal sets DBusName=org.freedesktop.secrets, so that bus name never exists and the call simply times out — which reads exactly like "still broken". Probe the frontend instead:

busctl --user introspect org.freedesktop.portal.Desktop /org/freedesktop/portal/desktop | grep -i secret

Also worth adding to repro instructions: the app must be fully killed between attempts, not window-closed (see #78798 §3) — otherwise the surviving process absorbs the relaunch and neither new flags nor new portal config take effect. This produced several misleading test runs before I noticed.

Third environment (Hyprland), but the useful part is below: I went through the bundled app.asar and found the exact branch where this decision is made.

Environment: claude-desktop 1.24012.9 (Electron 42.7.0, Chrome 148.0.7778.280), Arch/Omarchy, Hyprland 0.56.0, XDG_CURRENT_DESKTOP=Hyprland, gnome-keyring 50.0, org.freedesktop.secrets on the bus, default collection unlocked. Installed from the AUR package, which extracts the official .deb payload verbatim and only adds Debian→Arch path symlinks for the Cowork VM stack (plus dropping the Debian-only lintian files) — so this is upstream's build, not a repackaging artifact.

Same fingerprint as the two reports above:

{"os_crypt":{"portal":{"prev_desktop":"Hyprland","prev_init_success":false}}}

[warn] [safeStorage] isEncryptionAvailable=false on linux at startup (backend=basic_text) — session will not persist

--password-store=gnome-libsecret resolves it completely: Claude Safe Storage item created, warning gone, sign-in persists.

Why it happens, in the app's own code

The app doesn't rely solely on Chromium's detection — it has its own:

const desktop = () => {
  const d = (process.env.XDG_CURRENT_DESKTOP ?? "").toUpperCase().split(":");
  return d.includes("KDE")   ? "kde"
       : d.includes("GNOME") ? "gnome"
       : (!process.env.XDG_CURRENT_DESKTOP && process.env.KDE_FULL_SESSION) ? "kde"
       : "other";
};

password-store occurs four times in the bundle — three in code, one inside a log string:

1. A kwallet pre-flight, guarded by desktop() !== "kde" → early return
2. desktop() === "kde" && !commandLine.hasSwitch("password-store") → probe org.kde.kwalletd{5,6} over D-Bus
3. appendSwitch("password-store", "basic") — when kwalletd is reachable but has no wallet

Which means:

| desktop() | Behaviour |
|---|---|
| kde | Probed over D-Bus and handled |
| gnome | Detected — but the only use I can find for the value is picking a tray icon, never password-store. Works anyway, because Chromium recognises GNOME. |
| other | No branch at all. Falls through to Chromium's failed-portal autodetect. |

The app never calls appendSwitch("password-store", "gnome-libsecret") anywhere — the only value it ever sets is "basic". Crostini (X-Generic), Sway and Hyprland all land in other and inherit the fallback.

The fix mirrors code that already exists

The KDE path already probes D-Bus for the absence of a wallet in order to downgrade safely. What's missing is the same probe for the presence of a Secret Service, in order to upgrade:

if (desktop() === "other" && !app.commandLine.hasSwitch("password-store")) {
  // the same D-Bus helper already used for org.kde.kwalletd6
  // and org.freedesktop.portal.Desktop
  if (await dbusNameHasOwner("org.freedesktop.secrets"))
    app.commandLine.appendSwitch("password-store", "gnome-libsecret");
}

This is strictly safer than the KDE branch that already ships: it upgrades rather than downgrades, and only when the service actually answers on the bus.

Not a niche configuration

XDG_CURRENT_DESKTOP=Hyprland isn't something the user sets. It comes from DesktopNames=Hyprland in /usr/share/wayland-sessions/hyprland.desktop, shipped by the hyprland package itself — the same mechanism gives Sway its value. Every user of these compositors gets a string the app classifies as other, by default, with no way to influence it short of lying about their desktop (which breaks xdg-desktop-portal screen sharing).

hyprland is packaged in Debian (trixie-backports, forky, sid), so this reproduces on the official .deb on a supported distribution.

Secondary

The warning text should name the backend that was actually selected. "Install and unlock a system keyring (such as GNOME Keyring)" is actively misleading when a keyring is installed, running and unlocked — which is the case in all three reports on this issue. Something like "secure storage unavailable (backend: basic_text)" would at least be diagnosable.

Still present in 1.40609.0.

My environment: Void Linux, labwc/wlroots, XDG_CURRENT_DESKTOP=labwc:wlroots → other in the desktop() branch @ocewers identified. claude-desktop installed from the official .deb package. gnome-keyring running, org.freedesktop.secrets on the bus, collection unlocked.

Same fingerprint:

{"os_crypt":{"portal":{"prev_desktop":"labwc:wlroots","prev_init_success":false}}}

key_storage_linux.cc:116] Selected backend for OSCrypt: BASIC_TEXT
key_storage_linux.cc:135] OSCrypt did not initialize a backend.

--password-store=gnome-libsecret fixes it.

The warning never reaches the user

Fresh, empty --user-data-dir. main.log has the detection:

[warn] [safeStorage] isEncryptionAvailable=false on linux at startup (backend=basic_text) — session will not persist; app secrets fall back to plaintext

but no insecure-storage notice scheduled line and no toast. 125 [info] lines in the same file, so the level isn't masking it; the profile was empty, so the persisted insecureStorageNoticeShown flag doesn't explain it either.

Even when it fires, a one-shot toast on a 5s timer — early-returning on a persisted flag, racing window readiness — is the wrong mechanism for a permanent condition that is re-detected at every startup.

Why it's hard to diagnose

The symptom isn't "sign-in won't be saved". The session cookie outlives the missing refresh token, so it presents as a forced magic-link login every 1–2 days, citing only security reasons — the session-expiry message. That reads as server-side policy, not local storage. Four days to find the Chromium line above, which needs --enable-logging=stderr --v=1 since child processes run with --disable-logging.

Suggestion

Besides the D-Bus probe @ocewers proposed: make the insecure-storage state persistent rather than a one-shot toast, and have the re-login prompt name the cause when isEncryptionAvailable() is false — that prompt is the one users actually see.