Skip to content

Claude Desktop 1.20186.1

Choose a tag to compare

View all tags
@github-actions github-actions released this 13 Jul 08:18
v1.20186.1
a2f4721

Claude Desktop 1.20186.1

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

NixOS / Nix

nix run github:patrickjaja/claude-desktop-bin

AppImage (Any Distro)

# x86_64
chmod +x Claude_Desktop-1.20186.1-x86_64.AppImage
./Claude_Desktop-1.20186.1-x86_64.AppImage
# ARM64
chmod +x Claude_Desktop-1.20186.1-aarch64.AppImage
./Claude_Desktop-1.20186.1-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) f8b9807b257231c53f8af780ef554d7b2d0dc237cb1c4558119f86675ca383be
Tarball (aarch64) 253cba24e4c45d5619919b1e6ac73a194e9b6d2351cc545f00ff0bb1dc186a9f
AppImage (x86_64) 42cd9227f58642e3f3898ce65303f5f06373b3bc64fc955cf6094efc18f9cb65
AppImage (aarch64) dbe46c7d711ead68410701ce60d9ba1c64eb209ebaa5b0163cd77e7892824b8f
Debian (amd64) 2789f597a86ef887b6fc758836e7bf0a0b1d4995380fa6fadf7da5a0f3fed097
Debian (arm64) 41e68606fd2b63487f0eb2becd1a0c1fdfaec4bf1cbd40a2e259de3834a502c7
RPM (x86_64) 644257b38cddabbc73ac73eb52a461e1b8e35621f1320387addea15a9a7b538f
RPM (aarch64) dd9d6ddedfd646a418ffca02cc545b4107d7245fe20d83378c53917f02ad4268

Changes since last release

v1.20186.1: four patches re-fitted after the upstream bump (#192)

Upstream released v1.20186.1 (full re-minify; the code-split main bundle grew from ~45 to 82 chunks) and the auto-release failed on four patches. All four were upstream refactors of our anchor sites, not upstreamed features - every patch stays active:

  • fix_computer_use_linux (4 sub-patches): the CU lock field was renamed holder -> exclusiveHolder and acquire() restructured into an early-return shape; the screenshot intro-note seed re-anchored past a new takeover-approval flow in the tool wrapper; the handleToolCall isEnabled ternary arms became method calls (n.isComputerUseEnabled()). 36/36 sub-patches apply.
  • fix_builtin_mcp_open_url_handler: the 82-chunk split introduced a second, unrelated module using safeStorage.decryptString, breaking the bundle-global "exactly one electron var" discovery. The scan is now scoped to the chunk containing the msal-cache-get injection site (still fails loud on any ambiguity).
  • fix_asar_folder_drop: the second-instance argv loop gained a leading directory-collector block; folded into the pattern.
  • fix_imagine_linux: the hasImagine flag read became a member call (o.isFeatureEnabled("3444158716")); the callee matcher now accepts dotted paths. The flag ID itself is unchanged.

The parallel audits confirmed a mechanical bump otherwise: the capability map is identical (41 keys), no new platform gates, no new native modules, no new PORTABLE Linux opportunities, Electron unchanged at 42.5.1. Notable upstream changes: a new "heavy work" utility process that computes Claude Code usage stats from ~/.claude/projects, and agent-sdk 0.3.202 -> 0.3.205. GrowthBook delta: +3602629573 (process kill-switch), -1295378343 (CLI stream robustness) - the overrides template and docs catalog are updated; a new launch async feature override (flag 2976814254) is already force-enabled by the existing Code/Cowork enablement patch. ion-dist grew 102 -> 128 MB from three new code-split chunks, no structural changes.

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