patrickjaja/claude-desktop-bin v1.11847.5-3

Claude Desktop 1.11847.5 (patch release 3)

on GitHub

Claude Desktop 1.11847.5 (patch release 3)

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

NixOS / Nix

nix run github:patrickjaja/claude-desktop-bin

AppImage (Any Distro)

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

Issue

• #128: [CliGovernor] memory pressure (critical) log spam on Linux plus silent renderer "eviction" forcing a claude.ai re-login. Root cause of the spam: Electron's process.getSystemMemoryInfo().free is MemFree on Linux, which excludes reclaimable page cache. A healthy 32 GB box measured MemFree/MemTotal = 5.3% while MemAvailable/MemTotal = 61.8%, so the governor (warning <5%, critical <2%, 10s poll, M$r=.05/N$r=.02 in v1.11847.5) fires constantly on perfectly healthy systems. The pressure events only log + send telemetry - they never touch the renderer. Separately, the main webview's render-process-gone handler early-returns with no log when the reason is killed/clean-exit or an expected kill is pending - a kernel OOM SIGKILL maps to killed, so the renderer death that precedes the re-login was invisible in main.log (the reporter's "no render-process-gone events" proved nothing).

New patches (2)

• fix_cli_governor_memavailable.nim - rewrites getFreeMemoryRatio to read MemAvailable/MemTotal from /proc/meminfo (clamped with Math.min(1, ...)), re-emitting the captured upstream expression verbatim as the fallback if the /proc read throws. require("fs") is cached by Node's module loader, so the 10s poll costs one ~1.5 KB procfs read. Idempotency marker: /proc/meminfo within 200 chars of getFreeMemoryRatio:. macOS is unaffected (native pressure events bypass the polling path). Upstream's own MCP timeout diagnostics already compensate with free + fileBacked elsewhere - the governor just never got the fix.
• fix_renderer_gone_suppressed_log.nim - inserts D.info("Main webview render process gone (suppressed): %o",{reason,exitCode,expectedKills}) inside the early-return branch of the main-webview render-process-gone handler, before the counter decrement (expectedKills > 0 = app-initiated kill via the unresponsive handler; 0 with reason killed = external kill, e.g. kernel OOM). All identifiers captured via [\w$]+ groups; the trailing "Main webview render process gone: %o" literal pins the one correct site out of 8 render-process-gone registrations. Pure observability - suppression behavior (no reload) unchanged.

Tooling

• scripts/validate-patches.sh - added a nim-dir branch (copy directory to a temp dir, run the binary on it) and a directory-aware existence check. Previously fix_ion_dist_linux.nim always failed standalone validation with "target file not found" because the script -f-tested its directory target; suite is now 51/51.

Not addressed (still open in #128)

• preferencesChanged MaxListeners warning - upstream claude.ai web-app bug (the shipped preload's onPreferencesChanged correctly returns an unsubscribe closure; the remote web app re-subscribes without cleanup). Trivial magnitude (~KBs per page session); masking it would hide real regressions.
• The re-login mechanism itself - the claude.ai view runs on persistent session.defaultSession and the recovery path is a plain webContents.reload(), so the web session should survive; needs incident-time evidence from the reporter (asks posted on the issue).

Verification

• Patch count 48 -> 50; both new patches idempotent (second run exits 0 via marker detection); node --check passes on the patched JS; ./scripts/validate-patches.sh 51/51 green; pure-JS text patches, identical on x86_64 and aarch64.

Launcher log rotation (#132)

Credit: boommasterxd (Yannick Schäfer) - triaged #132 (located the reported awk hang in aaddrick/claude-desktop-debian, not this repo) and contributed the rotation fix (#133). Merged after the -2 release - ships with the next release, not in the v1.11847.5-2 artifacts.

• Issue: #132: Reported that _previous_launch_hit_gpu_fatal hangs the launcher on large log files via an O(n^2) awk scan of the whole launcher.log on every startup. Investigation result: that function, setup_logging, build_electron_args and the ~/.cache/claude-desktop-debian/ cache path do not exist anywhere in this repo - they belong to the separate aaddrick/claude-desktop-debian project. This launcher writes to ~/.cache/claude-desktop/launcher.log and only ever reads it via tail -10 for --diagnostics, so the reported O(n^2) hang cannot occur here. The one applicable half of the report - unbounded log growth - did apply: log() appended without any size cap.
• Fix: scripts/claude-desktop-launcher.sh - rotate launcher.log to launcher.log.old once it exceeds 2 MiB, checked once per startup before log() is defined. Every step is guarded (stat failure -> 0, numeric regex guard, mv failure ignored) so the rotation can never itself prevent Claude from launching.
• Post-merge fixup: _diagnose's "Recent launcher log" section now reads across the rotated backup (cat launcher.log.old launcher.log 2>/dev/null | tail -10 || true) so the last 10 lines survive a rotation that just happened at startup. The || true is required under the launcher's set -euo pipefail: cat exits non-zero when one of the files is missing, which is the common state (no .old exists before the first rotation) and would otherwise abort --diagnose mid-output.

Links

• AUR Package
• Full Changelog