Linux: silent connection death + device key loss from gnome-keyring + confusing quit behavior

Status Open

Maintainer reply None cached

Activity 3 comments · opened Jul 18, 2026

Linux: silent connection death + device key loss + confusing quit behavior

Environment: Claude Desktop 1.22209.0 (Electron 42.5.1) + Claude Code, Debian 13 (trixie), GNOME/Wayland, wifi (iwlwifi). Same symptoms previously observed on NixOS — not distro-specific. User has reinstalled Linux three times trying to fix this.

1. Silent dead connections — no error, app just hangs (main issue)

Behind a NAT that purges idle connections (~30 min), both Claude Desktop and Claude Code end up with dead TCP connections. Symptoms:

The app becomes unresponsive/slow after 1–2 h of a session.
No error message, no "reconnecting…" indicator, nothing. The user has no way to know the connection to the server is gone; it just "lags forever" until they kill and restart the app.
main.log shows [remote-tools-device] reconnect #1 every ~30 min (10:01, 10:30, 10:57, 11:28, 12:00…), but API/session connections don't recover the same way.

Root cause on the client side: the app relies on OS TCP keepalive, and the Linux default is tcp_keepalive_time=7200 (2 h) — so a NAT-killed connection is never detected. Workaround that fixes it: set system-wide keepalive to 60 s.

Requests:

Enable application-level keepalive (or setKeepAlive with a sane interval, e.g. 60 s) on long-lived connections instead of relying on OS defaults.
Surface connection state in the UI: a visible "connection lost / reconnecting" indicator instead of silently hanging.

2. Device key lost from gnome-keyring → forced re-login

After restarting the app, login was forced with reason=elevated_auth&auth_kind=device_key_missing&from=logout. gnome-keyring-daemon was running and unlocked; login.keyring was rewritten at that time. Looks like Electron safeStorage backend detection failed at startup (known Electron/gnome-keyring race). Workaround: launching with --password-store=gnome-libsecret.

Request: pin/retry the safeStorage backend on Linux instead of falling back and losing the device key.

3. Closing the window doesn't quit, with no indication

Closing the Claude Desktop window leaves the full process tree running in the background (no tray icon visible under stock GNOME, which has no system tray by default). Users who "closed" the app to restart it find it still running, old flags still active. The only reliable way to quit is pkill.

Request: either quit on window close on Linux/GNOME, or make the background state discoverable (and provide a real "Quit" menu item).

4. "Valider les modifications" commit bar cannot be hidden

In Claude Code sessions inside Desktop, the commit bar ("Valider les modifications", +N −N) is hardcoded with no setting to hide it. For users who commit from the terminal themselves, it is permanent visual noise and reads as if changes were pending/blocked when they are already on disk.

Request: a setting to hide the commit bar, or at least clearer wording that changes are already written and the button is only an optional git commit.

View original on GitHub ↗

3 Comments

srgvg · 27 days ago

§3 reproduces on Sway too, so it isn't specific to GNOME's lack of a tray — it affects any compositor without a system tray.

Environment: claude-desktop 1.24012.9 (official apt), Debian 13 trixie, sway 1.12 / wlroots 0.20.

Closing the window leaves the full process tree alive:

$ pgrep -f 'lib/claude-desktop/claude-desktop' | wc -l
12

The window is gone from swaymsg -t get_tree, but the process persists and keeps the single-instance lock, so relaunching from the menu is silently absorbed — no window appears and nothing indicates why.

The consequence worth adding to the report: this silently invalidates configuration testing. While debugging the safeStorage issue (#77913) I relaunched with new Electron flags several times, and each relaunch was absorbed by the surviving instance — so the process under test was always the original no-flag one, and the results looked like "the flags do nothing". Checking the main pid is the only way to know which flags are actually live:

tr '\0' ' ' < /proc/<main-pid>/cmdline

The same applies to portal and environment changes: they cannot take effect until the tree is killed.

Endorsing the request in §3: a real Quit item, or quit-on-close where no tray exists.

grammy-jiang · 6 days ago

Additional Claude Desktop reproduction: Raspberry Pi OS / labwc / arm64

Adding only information not already covered in section 2 or the focused Crostini report, #77913.

This is reproducible outside Crostini on a bare-metal Raspberry Pi 5:

Official Anthropic claude-desktop APT package 1.34493.1, arm64
Electron 42.9.2
Debian 13 / Raspberry Pi OS, Wayland
XDG_CURRENT_DESKTOP=labwc:wlroots
DESKTOP_SESSION=rpd-labwc
GNOME Keyring 48.0-1; libsecret 0.21.7-1

Before applying the command-line workaround, ~/.config/Claude/Local State recorded:

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

At the same time, org.freedesktop.secrets was registered, and the default collection returned Locked=false. Claude logged:

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

An A/B test with the same installation confirmed that --password-store=gnome-libsecret caused Claude to write to the existing keyring. On the next restart, Claude loaded the persisted OAuth token cache from disk.

This extends the affected scope beyond ChromeOS/Crostini and X-Generic: the portal-to-basic_text fallback also occurs on Raspberry Pi OS under labwc:wlroots, and it remains present in Claude Desktop 1.34493.1 with Electron 42.9.2.

Electron has since added asynchronous safeStorage support that probes the Freedesktop Secret Service directly and handles temporary backend unavailability. That API appears relevant here: electron/electron#49054.

catsbarla · 6 days ago

it's a true shame how your two apps (cli+desk) malfunction, as I do
experience every single day : I've resigned my $200/mth subscription
because of that : try work harder using claude, that should eventually
work...

Le lun. 24 août 2026 à 15:30, Grammy Jiang @.***> a
écrit :

grammy-jiang left a comment (anthropics/claude-code#78798) <https://github.com/anthropics/claude-code/issues/78798#issuecomment-5395917668> Additional Claude Desktop reproduction: Raspberry Pi OS / labwc / arm64 Adding only information not already covered in section 2 or the focused Crostini report, #77913 <https://github.com/anthropics/claude-code/issues/77913>. This is reproducible outside Crostini on a bare-metal Raspberry Pi 5: - Official Anthropic claude-desktop APT package 1.34493.1, arm64 - Electron 42.9.2 - Debian 13 / Raspberry Pi OS, Wayland - XDG_CURRENT_DESKTOP=labwc:wlroots - DESKTOP_SESSION=rpd-labwc - GNOME Keyring 48.0-1; libsecret 0.21.7-1 Before applying the command-line workaround, ~/.config/Claude/Local State recorded: { "os_crypt": { "portal": { "prev_desktop": "labwc:wlroots", "prev_init_success": false } } } At the same time, org.freedesktop.secrets was registered, and the default collection returned Locked=false. Claude logged: [safeStorage] isEncryptionAvailable=false on linux at startup (backend=basic_text) — session will not persist; app secrets fall back to plaintext An A/B test with the same installation confirmed that --password-store=gnome-libsecret caused Claude to write to the existing keyring. On the next restart, Claude loaded the persisted OAuth token cache from disk. This extends the affected scope beyond ChromeOS/Crostini and X-Generic: the portal-to-basic_text fallback also occurs on Raspberry Pi OS under labwc:wlroots, and it remains present in Claude Desktop 1.34493.1 with Electron 42.9.2. Electron has since added asynchronous safeStorage support that probes the Freedesktop Secret Service directly and handles temporary backend unavailability. That API appears relevant here: electron/electron#49054 <https://github.com/electron/electron/pull/49054>. — Reply to this email directly, view it on GitHub <https://github.com/anthropics/claude-code/issues/78798?email_source=notifications&email_token=CFAXPJKEJVDSYEOD5LJ3S3D5LQ7P3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZZGU4TCNZWGY4KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5395917668>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CFAXPJMJXNZ6LQ7DN4X4PYL5LQ7P3AVCNFSNUABFKJSXA33TNF2G64TZHM4TGNZSGUZTINZVHNEXG43VMU5TIOJRG44DMNJSGE3KC5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/CFAXPJMBVYGTJDMWRTGLIX35LQ7P3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZZGU4TCNZWGY4KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KUZTPN52GK4S7NFXXG> and Android <https://github.com/notifications/mobile/android/CFAXPJKM35HU6V6Y5JCOUL35LQ7P3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKMZZGU4TCNZWGY4KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2K4ZTPN52GK4S7MFXGI4TPNFSA>. Download it today! You are receiving this because you authored the thread.Message ID: @.***>