[BUG] Linux .deb Recommends a nonexistent package (kwalletd6), pulling gnome-keyring onto KDE systems

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version — see the version section; the defect is confirmed present in the current candidate 1.46388.2

What's Wrong?

The Claude Desktop .deb declares its KDE keyring alternatives under package
names that do not exist in the Ubuntu/Debian archive:

$ dpkg-query -W -f='${Recommends}\n' claude-desktop
... gnome-keyring | kwalletd6 | kwalletd5, ...

Neither kwalletd6 nor kwalletd5 is a real package:

$ apt-cache policy kwalletd6
kwalletd6:
Installed: (none)
Candidate: (none)

$ apt-cache policy kwalletd5
kwalletd5:
Installed: (none)
Candidate: (none)

The real package is kwallet6; kwalletd6 is the binary it ships:

$ dpkg -S /usr/bin/kwalletd6
kwallet6: /usr/bin/kwalletd6

$ apt-cache policy kwallet6
kwallet6:
Installed: 6.24.0-0ubuntu1

apt-cache showpkg kwalletd6 confirms nothing else in the archive references
that name — the only reverse-dependency is claude-desktop itself:

Package: kwalletd6
Versions: (none)
Reverse Depends:
claude-desktop,kwalletd6

Because both KDE alternatives are unsatisfiable, APT falls through to the first
alternative that is satisfiable — gnome-keyring — and installs it on every
KDE system, including ones where KWallet is already installed and working. That
leaves two Secret Service providers competing for org.freedesktop.secrets.

The two race at login, and when gnome-keyring wins, Electron's safeStorage
cannot obtain a key and the app refuses to persist the session, showing:

Your sign-in won't be saved on this device. Install and unlock a system keyring (such as KDE Wallet (KWallet)), then restart the app.

...on a machine that had a working keyring before Claude Desktop was installed.

What Should Happen?

On a KDE system with kwallet6 already installed, installing claude-desktop
should recognise the existing Secret Service provider and not pull in a second,
competing one. Sign-in should persist across restarts without manual
intervention.

Suggested fix — correct the package name in debian/control:

-Recommends: ... gnome-keyring | kwalletd6 | kwalletd5, ...
+Recommends: ... gnome-keyring | kwallet6 | kwalletd5, ...

Worth considering additionally: ordering the alternatives by session type, or
demoting this to Suggests:. Any Secret Service implementation satisfies the
real runtime requirement — the app reaches org.freedesktop.secrets / the XDG
Secret portal through libsecret — so listing gnome-keyring unconditionally
first guarantees a redundant provider on KDE installs.

Error Messages/Logs

$ busctl --user list | grep -i secret
org.freedesktop.impl.portal.desktop.kwallet   1825 ksecretd
org.freedesktop.secrets                       1795 gnome-keyring-d
org.kde.ksecretd                              1825 ksecretd
org.kde.secretservicecompat                   1825 ksecretd

$ grep 'gnome-keyring' /var/log/dpkg.log
2026-09-02 18:04:52 configure gnome-keyring:amd64 50.0-1 <none>
# ...same transaction as claude-desktop

$ zcat /var/log/installer/initial-status.gz | grep -c '^Package: gnome-keyring$'
0
# the distro did not ship it; the claude-desktop install pulled it in

Steps to Reproduce

1. Install Kubuntu 26.04 (Plasma 6). Confirm the starting state — KWallet

present, gnome-keyring absent:

apt-cache policy kwallet6 gnome-keyring

1. Install Claude Desktop from the Anthropic APT repository:

sudo apt install claude-desktop

1. Observe that gnome-keyring was pulled in as a Recommends, in the same dpkg

transaction:

grep 'gnome-keyring' /var/log/dpkg.log

1. Reboot. Both gnome-keyring-daemon --components=pkcs11,secrets and KDE's

ksecretd / kwalletd6 now start at login.

1. Confirm the split ownership — gnome-keyring holds org.freedesktop.secrets

while ksecretd holds the KDE portal backend:

busctl --user list | grep -i secret

1. Launch Claude Desktop. Depending on which daemon wins the startup race, the

"sign-in won't be saved" warning appears and the session is not persisted.

Removing the wrongly-installed package resolves it, which confirms the cause:

sudo apt remove gnome-keyring

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Claude Code Version

N/A — this is Claude Desktop for Linux, not the Claude Code CLI.

Running claude-desktop 1.40609.1, but the defect is not version-specific:
the faulty Recommends line is byte-identical in every version currently
offered by Anthropic's APT repository, including the latest.

$ for v in 1.40609.1 1.44121.2 1.46388.2; do
apt-cache show claude-desktop=$v | grep -E '^(Version|Recommends):'
done
Version: 1.40609.1
Recommends: ... gnome-keyring | kwalletd6 | kwalletd5, ...
Version: 1.44121.2
Recommends: ... gnome-keyring | kwalletd6 | kwalletd5, ...
Version: 1.46388.2
Recommends: ... gnome-keyring | kwalletd6 | kwalletd5, ...

Upgrading does not resolve it.

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

Ubuntu 26.04.1 LTS (Kubuntu), Plasma 6, XDG_CURRENT_DESKTOP=KDE.
Relevant versions: kwallet6 6.24.0-0ubuntu1, plasma-workspace
4:6.6.6-0ubuntu0.1, libpam-kwallet5 4:6.6.4-0ubuntu1.

Note that /etc/pam.d/sddm ships pam_gnome_keyring.so auto_start alongside
pam_kwallet5.so auto_start. That is not itself the bug — the lines are
optional and inert when gnome-keyring is not installed. It only becomes a
problem once something installs gnome-keyring on a KDE system, which is what
this dependency does.

Not a duplicate of #77913, which shares the error string but has a different
cause. That report is Chromium's portal backend failing to initialise on
ChromeOS/Crostini, where XDG_CURRENT_DESKTOP=X-Generic and no implementation
of org.freedesktop.impl.portal.Secret exists. Here the portal backend
initialises fine and the desktop is correctly detected as KDE:

$ grep -o '"os_crypt":{[^}]*}' ~/.config/Claude/Local\ State
"os_crypt":{"portal":{"prev_desktop":"KDE","prev_init_success":true}

prev_init_success is true here and false in #77913. That flag cleanly
separates the two. This issue is upstream of backend selection entirely: the
.deb installs a second Secret Service provider that should never have been
installed, and the two then race. Fixing #77913's fallback logic would not
prevent that; fixing the package name would.

#80494 (relogin required each session on Linux) may share this root cause, but
it does not identify one, so I am filing separately rather than commenting there.

Possibly related, though again a different root cause (backend selection rather
than dependency naming) and a third-party repackager rather than the official
.deb: https://github.com/aaddrick/claude-desktop-debian/issues/719