patrickjaja/claude-desktop-bin v1.21459.3

Claude Desktop 1.21459.3

on GitHub

Claude Desktop 1.21459.3

This release provides Claude Desktop version 1.21459.3 pre-patched for Linux.

Installation Options

Arch Linux (AUR)

yay -S claude-desktop-bin

Debian/Ubuntu (APT Repository — recommended)

curl -fsSL https://patrickjaja.github.io/claude-desktop-bin/install.sh | sudo bash
sudo apt install claude-desktop-bin

Debian/Ubuntu (manual .deb)

# x86_64
sudo apt install ./claude-desktop-bin_1.21459.3-1_amd64.deb
# ARM64
sudo apt install ./claude-desktop-bin_1.21459.3-1_arm64.deb

Fedora/RHEL (RPM Repository — recommended)

curl -fsSL https://patrickjaja.github.io/claude-desktop-bin/install-rpm.sh | sudo bash
sudo dnf install claude-desktop-bin

Fedora/RHEL (manual .rpm)

# x86_64
sudo dnf install ./claude-desktop-bin-1.21459.3-1.x86_64.rpm
# ARM64
sudo dnf install ./claude-desktop-bin-1.21459.3-1.aarch64.rpm

NixOS / Nix

nix run github:patrickjaja/claude-desktop-bin

AppImage (Any Distro)

# x86_64
chmod +x Claude_Desktop-1.21459.3-x86_64.AppImage
./Claude_Desktop-1.21459.3-x86_64.AppImage
# ARM64
chmod +x Claude_Desktop-1.21459.3-aarch64.AppImage
./Claude_Desktop-1.21459.3-aarch64.AppImage

Update existing AppImage (delta download — only changed blocks):

appimageupdatetool Claude_Desktop-*-x86_64.AppImage
# Or from within the AppImage:
./Claude_Desktop-*-x86_64.AppImage --appimage-update

Checksums

Changes since last release

Updated to Claude Desktop v1.21459.0

Routine upstream bump. Computer Use is still macOS/Windows-only upstream, so our Linux Computer Use support stays. One tool-description tweak re-fitted (open_application on Linux no longer tells the model to request allowlist access first, since our bridges reach every app). No new Linux-relevant changes upstream.

App identity aligned to upstream: com.anthropic.Claude

All packages now ship the official build's app identity end to end. Previously the build pinned the bundle's desktopName back to claude-desktop.desktop and named every .desktop file, StartupWMClass, and systemd scope to match. The pin is removed: the bundle keeps upstream's desktopName (com.anthropic.Claude.desktop), every package (AUR, deb, rpm, AppImage, Nix) installs com.anthropic.Claude.desktop with StartupWMClass=com.anthropic.Claude, the launcher scope is app-com.anthropic.Claude-PID.scope, and the claude:// handler registers on the new name. A build tripwire fails loud if upstream ever renames desktopName again.

The point of the reverse-DNS id: xdg-desktop-portal resolves an unsandboxed app from its systemd scope back to a .desktop file, which is what makes portal activation routing and KDE's persistent screen-share / Computer Use grants work. The single-segment claude-desktop id could not do that, and keeping it meant permanent naming drift from the official package.

One-time migration on upgrade:

• Pinned taskbar/dock shortcuts referencing the old claude-desktop.desktop orphan - re-pin once (deliberately no compat symlink: it would surface a duplicate app entry in launchers).
• Custom WM rules matching claude-desktop need updating to com.anthropic.Claude.
• KDE screen-share / Computer Use consent asks once more (portal grants are keyed to the app id), then persists - persistence is precisely what the reverse-DNS id fixes.
• Named profiles: per-profile .desktop files become com.anthropic.Claude-<name>.desktop; --delete-profile cleans up both old and new names. The window app_id itself is shared across profiles; distinct per-profile grouping needs a per-profile desktopName override (follow-up).
• Quick Entry keeps its own claude-quick-entry id. Launcher binary (claude-desktop), icon name, and userData (~/.config/Claude) are all unchanged - no re-login.

kwin-portal-bridge 0.2.4: Computer Use screenshots fixed on KDE Plasma Wayland (kwin-portal-bridge#1)

Two bridge bugs broke screenshots on KDE Plasma Wayland (reported on 6.7.2): the KWin helper script declared its DBus constants after the functions that close over them, which KWin's QJSEngine rejects ("Variable 'DBUS_DESTINATION' is used before its declaration") - so window-control scripts never ran; and un-activatable plasmashell overlay surfaces (OSD/notifications) in the pre-capture activation set aborted the whole preparation, cascading into "session daemon did not become ready in time". Window activation is now gated to activatable windows and best-effort, the constants precede the header, and a separate race (activation verified with a single immediate read of the active window) polls for the requested window instead. Bundled bridge is now 0.2.4 with regression tests for both fixes.

--diagnose: new Computer Use section

claude-desktop --diagnose now prints the installed package version (which pins every bundled bit, bridges included), bundled-bridge presence, and - on KDE Wayland - the KWin version with the >= 6.6 gate verdict plus a portal-free windows enumeration self-test through the kwin-portal-bridge, the exact KWin scripting path the 0.2.4 fixes repair. No consent dialog is opened and window titles are never included in the output. The README now also states the KDE Plasma 6.6 floor for the native KWin route explicitly.

Removed 4 patches: we no longer keep "guard-only" patches

Dropped 4 patches (41 -> 37) that no longer modified the bundle and only asserted upstream's own behavior: the CLI-governor memory fix (#128), the /etc/claude-desktop/managed-settings.json reader (main + boot bundle), and the title-bar fix - all native in the official build. We keep only patches that modify the bundle.

KDE Plasma Wayland no longer misrouted to the "exotic" XWayland fallback (#194)

Computer Use on a KDE Plasma 6.6+ Wayland session could fall through to the "exotic - ydotool/x11-bridge" fallback (ending on XWayland) instead of the native kwin-portal-bridge. The mode gate in cu_mode_preamble.js keyed off XDG_SESSION_DESKTOP === "KDE" - an exact-match on a variable set by the display manager, whose value is not standardized (SDDM/GDM may report plasma, an absolute path, or nothing). The downstream DE detection in cu_linux_executor.js used the reliable XDG_CURRENT_DESKTOP (Plasma sets it to KDE), so the two disagreed: diagnostics printed de=kde while the bridge was never selected. The gate now keys off XDG_CURRENT_DESKTOP (case-insensitive substring) and accepts WAYLAND_DISPLAY as a Wayland signal, matching the downstream logic and the label the kwin-portal-bridge itself reads. The KWin >= 6.6 version probe still guards the route, so a non-KWin or too-old session correctly falls back.

Diagnostics surface the raw session env behind KDE routing

To make a future routing mismatch diagnosable without shell access, --diagnose now prints XDG_SESSION_DESKTOP next to XDG_CURRENT_DESKTOP, and the runtime [claude-cu] diagnostics: block adds a line with the raw XDG_CURRENT_DESKTOP / XDG_SESSION_DESKTOP / XDG_SESSION_TYPE values plus the resolved kwin-mode. A de=kde with kwin-mode=false now reads as a self-explaining signature in claude-patches.log.

Quick Entry no longer restores a stale window app_id after first use

After Quick Entry is shown, fix_quick_entry_app_id resets CHROME_DESKTOP so later windows get the main app_id back. That reset target was a hardcoded claude literal, but upstream renamed the app identity (desktopName) to com.anthropic.Claude in v1.19367.0, so on Wayland compositors that create a separate toplevel after Quick Entry (GNOME, wlroots) those windows could inherit a stale, non-matching app_id - breaking taskbar/dock grouping and per-app window rules. The reset now reads desktopName from the app's own package.json at runtime (falling back to the literal only if that read fails), so it can't go stale on the next upstream rename. Verified non-breaking on KDE Plasma 6 Wayland (main window kept the then-pinned claude-desktop, Quick Entry claude-quick-entry; with the app-identity alignment above, the runtime read now resolves the main id to com.anthropic.Claude).

Launcher: CLAUDE_GPU_BACKEND=angle-gl escape hatch

New opt-in launcher env var that renders via ANGLE's GL backend (--use-gl=angle --use-angle=gl) instead of the native Wayland/GBM path. Some GPU + kernel-driver combos (e.g. Intel xe) abort Electron's Ozone/Wayland GPU-process init ("GPU process isn't usable. Goodbye.") but work fine through ANGLE-GL, which keeps GPU acceleration - a milder fallback to try before CLAUDE_DISABLE_GPU.

Links

• AUR Package
• Full Changelog