Skip to content

Claude Desktop 1.19367.0 (patch release 5)

Choose a tag to compare

View all tags
@github-actions github-actions released this 13 Jul 06:00
v1.19367.0-5
c58c2e6

Claude Desktop 1.19367.0 (patch release 5)

This release provides Claude Desktop version 1.19367.0 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.19367.0-5_amd64.deb
# ARM64
sudo apt install ./claude-desktop-bin_1.19367.0-5_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.19367.0-5.x86_64.rpm
# ARM64
sudo dnf install ./claude-desktop-bin-1.19367.0-5.aarch64.rpm

NixOS / Nix

nix run github:patrickjaja/claude-desktop-bin

AppImage (Any Distro)

# x86_64
chmod +x Claude_Desktop-1.19367.0-x86_64.AppImage
./Claude_Desktop-1.19367.0-x86_64.AppImage
# ARM64
chmod +x Claude_Desktop-1.19367.0-aarch64.AppImage
./Claude_Desktop-1.19367.0-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

File SHA256
Tarball (x86_64) 4a0cec44b8b77642d53c3d155cf4f9925f212421ce62d62eba15150df48ad8fb
Tarball (aarch64) 36c00f4039cd5b5484504415300196cd0d2dbdb677853a00dfc5673ea44385c5
AppImage (x86_64) 1bdec446210dbac5be3bcff20a8e199cc1fa456e3116016b5fc4509ab97c1e81
AppImage (aarch64) 4493aa719ec606a2ad0731c905bd209c716a0614f22065ec1e786677407fe79a
Debian (amd64) ef0f3fcd2567692962f5f48fb62bba36f66c02c2e8bd3020fd786c3de6e24751
Debian (arm64) 8e38eddf8726be7c38a5813b645dd9000751e69668441147b4c0fc516daca4fd
RPM (x86_64) fe0e4fb55dc60cab51a86215fbc2757904b7947fb13850ec17dab97c2b255712
RPM (aarch64) c57d23847c9b82c215ca30f137e74568b34801dc5174d2eea2e1e50c9788624b

Changes since last release

Code tab fixed: Local sessions failed with "__cdb_sanitizeCwd is not defined" (#191)

On the v1.19367.0 packages, every Code-tab Local session failed - as "Trust check couldn't be completed" when picking a folder, or "Something went wrong: __cdb_sanitizeCwd is not defined" when sending a message. Chat was unaffected.

Root cause was ours, a consequence of the code-split re-plumbing above: fix_asar_workspace_cwd injects a path-sanitizer helper at the top of the bundle and rewrites five LocalSessions/startCodeSession bridge call sites to use it. On the staged concatenation both live in one file, but after the split-back the injection point (the index.js loader stub) and the call sites (two index.chunk-*.js files) are separate CommonJS modules - the module-scoped var helper was invisible to the chunks, and every bridge call threw ReferenceError on its first statement. That is also why main.log stayed silent: checkTrust died before reaching its own log line. The helper is now defined on globalThis; the stub's top level runs before it requires any chunk, so the definition is guaranteed visible at every call site.

Why no gate caught it: the strict per-site match counts validate on the concatenation, where a single scope really does exist; node --check on each split file passes because an unresolved identifier is a runtime error, not a syntax error; and the smoke test does not start a Code session. apply_patches.py now closes the class at the split-back chokepoint: any injected __cdb* identifier referenced in more than one chunk part must be defined via globalThis, otherwise the build fails loud. The guard was verified in both directions - it rejects the broken v1.19367.0-4 bundle and passes the fixed one. An audit of all other injected identifiers found no second instance of the pattern (the remaining cross-chunk helpers were already globalThis-based).

Launcher: sign-in now persists on Hyprland/sway/XFCE and other keyring-less-by-Chromium desktops (#191)

Chromium picks its encryption backend from XDG_CURRENT_DESKTOP. On desktops it does not map to a keyring backend - all wlroots compositors (Hyprland, sway, river, niri), COSMIC, and also XFCE/LXQt, which it maps to basic_text by policy - safeStorage.isEncryptionAvailable() is false, OAuth tokens do not persist across launches, and the app tells the user to "install and unlock a system keyring" they may already be running.

The launcher now detects a Secret Service (org.freedesktop.secrets, owned or D-Bus-activatable) on the session bus and, on those desktops, adds --password-store=gnome-libsecret automatically (suggested and verified by the #191 reporter on Hyprland). Desktops Chromium already handles (GNOME family -> libsecret, KDE -> kwallet) are left untouched. Escape hatches: an explicit --password-store=... argument always wins, CLAUDE_PASSWORD_STORE=<value> forces a backend, and CLAUDE_PASSWORD_STORE=auto disables the detection. One-time side effect on machines that previously ran on basic_text: data encrypted under the old hardcoded key cannot be read after the switch, so the first launch may ask you to sign in again - after that, sign-in finally sticks.

Links

Assets 12
Loading