Claude Desktop 1.18286.0 (patch release 3)

Claude Desktop 1.18286.0 (patch release 3)

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

NixOS / Nix

nix run github:patrickjaja/claude-desktop-bin

AppImage (Any Distro)

# x86_64
chmod +x Claude_Desktop-1.18286.0-x86_64.AppImage
./Claude_Desktop-1.18286.0-x86_64.AppImage
# ARM64
chmod +x Claude_Desktop-1.18286.0-aarch64.AppImage
./Claude_Desktop-1.18286.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)	58da35f1092c54a240617f51f9dd069ea90b0f6e04bbe44da69b579da9ca894b
Tarball (aarch64)	ae67e073dcf1b221498cba46c4c94a78c0ba04924972cb36f274e1cb80f86342
AppImage (x86_64)	df6c03b73d9e15c5635b0247890f48ef3d9cf07e105e4ffe09739d4e9103d59e
AppImage (aarch64)	4cc0dbd07d8fcd70b6cae1de1449a100435bfe52fc328879cb4ab20ae62132a5
Debian (amd64)	a1fa9b7d6bc71dbf0d5ddb693da5897fc42b6039fb73bd0e683f7f05c52d37c4
Debian (arm64)	14fda2b5426ae08750525c860a4187b8e12f5104e7df00e3eea8efa9a85444ad
RPM (x86_64)	d30389fde70e11899b903dfe74e0ff2e1edab1ce684b7e81ec1a11b6915f40cf
RPM (aarch64)	349203266904440669f1b31988051a9eb55e42f12819447db9621d2aa157a144

Changes since last release

Release pipeline fixed; gnome-portal-bridge floor corrected to glibc 2.39 / PipeWire 1.0.5+

The first release runs with the new bridges failed on three CI bugs, fixed in sequence: the static-linking verify step only accepted ldd's non-PIE phrasing ("not a dynamic executable") and rejected our genuinely-static static-pie musl binaries (which print "statically linked"); the bridge builds did not pass --locked, leaving them exposed to dependency re-resolution; and a comment apostrophe inside a single-quoted bash -c block truncated the docker command, leaking build steps onto the bare runner.

The fourth failure was real: gnome-portal-bridge never compiled on the ubuntu:jammy build base, because its pipewire client library (lamco-pipewire 0.4.x) needs the spa_video_info_raw layout and stream-time APIs (pw_stream_get_nsec, pw_stream_get_time_n, extended pw_time) that only exist in PipeWire >= 1.0.5. Ubuntu 22.04 (PipeWire 0.3.48) and Debian 12 (0.3.65) cannot even load such a binary - the documented jammy floor was never achievable. Decision: build on ubuntu:noble like kwin-portal-bridge. gnome-portal-bridge now requires glibc 2.39 + PipeWire 1.0.5 (Ubuntu 24.04+, Fedora 40+, Debian 13+); GNOME Wayland on older distros falls back to X11/XWayland or GNOME_PORTAL_BRIDGE_BIN. Docs updated across README, CLAUDE.md, and computer-use-dependencies.md.

Quick Entry: cursor + focus via bundled x11-bridge - xdotool and hyprland dropped from packaging

Quick Entry was the last consumer of xdotool (cursor position for monitor placement, window activation for focus) and the reason hyprland sat in the dependency lists. fix_quick_entry_position.nim now calls the bundled x11-bridge (cursor-position, activate-window) on X11/XWayland; on Hyprland it uses hyprctl, which ships with the compositor itself and needs no package. With that, xdotool and hyprland are gone from Arch optdepends, Debian/Ubuntu and Fedora/RHEL Suggests, and the Nix package inputs - on Nix this also stops callPackage from pulling the entire Hyprland compositor into the closure just for hyprctl. The remaining soft CU deps are only the residual tiers: ydotool (exotic Wayland compositors) and imagemagick+spectacle (KDE below Plasma 6.6).

Diagnostics visible again: new claude-patches.log (official build discards console output)

The official .deb Electron build silently discards main-process console.log/console.warn - not to the terminal, not to main.log, the lines just vanish (the file descriptors are healthy; proven by writing into /proc/<pid>/fd/1 directly while console.log in the same process produced nothing). All our patch diagnostics ([claude-cu], [quick-entry], [CustomThemes], [claude-profile-route], …) were therefore invisible since the pivot to the official .deb. They now go through an injected __cdbDiag sink that writes to ~/.config/Claude/logs/claude-patches.log (profile/3p-aware, 2 MiB rotation) and to raw fd 2, which does reach a terminal launch. Docs updated accordingly - "run from a terminal and copy the output" no longer works for console-based lines.

Bridge resolution simplified: fixed bundled path, like upstream's own binaries

The four CU bridges now resolve the same way upstream resolves its bundled binaries (e.g. chrome-native-host): the *_BRIDGE_BIN env override, else the fixed bundled locales/ dir - one shared resolver instead of three copy-pasted candidate loops. The $PATH fallback is gone: bridges ship in the package, so a missing bridge is a packaging bug that should fail loud, not be masked by a stray system binary.

Docs: one Computer Use entrypoint instead of per-distro sections

Since all four bridges are bundled, the near-identical "Computer Use - nothing to install" paragraphs in the Arch, Debian/Ubuntu, and Fedora/RHEL install sections were removed; the Installation intro now says it once and the ## Computer Use section is the single entrypoint. The NixOS note was trimmed to Cowork plus a one-sentence caveat linking to a new ## NixOS section in docs/computer-use-dependencies.md.

CI: install host gcc for the static bridge container builds

The first real run of the new x11-bridge/wlroots-bridge build steps failed with linker 'cc' not found: cargo build scripts always compile for the host gnu triple and need a host cc, even though the musl targets themselves link via rust-lld. Both container steps now install gcc + libc6-dev (still no cross-gcc or musl-gcc).

Computer Use: bundled wlroots-bridge + gnome-portal-bridge - every supported session is now first-party (no more ydotool/grim/gnome-screenshot)

Two new first-party bridges complete the Computer Use backend family, so every supported session type now ships a bundled binary and users install nothing:

• wlroots-bridge (github.com/patrickjaja/wlroots-bridge) serves Sway, Hyprland, and Niri via native Wayland protocols: virtual-pointer + virtual-keyboard for input, wlr-screencopy for screenshots, and foreign-toplevel for window listing and activation (activation verified working on all three compositors). Pure Rust, fully static (x86_64 + aarch64, runs on NixOS), daemonless, no permission dialogs. It replaces ydotool, grim, and the hyprctl / swaymsg+jq / niri msg window queries.
• gnome-portal-bridge (github.com/patrickjaja/gnome-bridge) serves GNOME Wayland via the XDG RemoteDesktop + ScreenCast portal with PipeWire capture. One system consent dialog per Computer Use session, scoped to the tool-use lock; on GNOME 46+ the grant persists via restore token and is never asked again. It replaces ydotool and the whole GNOME screenshot cascade (embedded python3+GStreamer portal script, gnome-screenshot+convert, gdbus), and adds best-effort window enumeration via GNOME Shell Introspect - a capability GNOME previously had none of. Floor: glibc 2.39 + PipeWire 1.0.5 (built on ubuntu:noble; see the pipeline-fix entry above), x86_64 + aarch64.

The third-party cascades for these sessions were removed from the executor, mirroring the earlier x11-bridge cutover: on wlroots and GNOME sessions the bridge is the path, with COWORK_SCREENSHOT_CMD as the only override and Electron desktopCapturer as the last-resort screenshot tier. ydotool remains only for exotic Wayland compositors (none of wlroots/GNOME/KDE), and spectacle+convert only for KDE without KWin 6.6+. Packaging was simplified accordingly: grim, jq, gnome-screenshot, glib2/libglib2.0-bin (gdbus), python-gobject/python3-gi, and gst-plugin-pipewire/gstreamer1.0-pipewire are gone from optdepends/Suggests across Arch, Debian/Ubuntu, Fedora/RHEL, and Nix; ydotool/imagemagick stay with residual-only descriptions. On NixOS the static bridges work as bundled; GNOME Wayland needs a natively built gnome-portal-bridge passed via .override { gnome-portal-bridge = ...; }.

CI builds both new bridges from their repos (cached by HEAD SHA, static assert for wlroots-bridge, glibc-2.39 floor check for gnome-portal-bridge) and bundles all four bridges into every package. Docs (README install sections, computer-use docs, support matrices) were rewritten for the new reality.

Computer Use: new bundled x11-bridge is the first-party X11 backend (no more xdotool/scrot/etc.)

X11 / XWayland Computer Use is now served by a bundled first-party binary, x11-bridge, instead of the third-party tools. It handles input, screenshots, and window activation natively by talking to the X server directly, and it fully replaces xdotool, scrot, imagemagick (import), wmctrl, and the X11 use of gnome-screenshot. There is no third-party fallback on X11 anymore - the bridge is the path. It is a fully-static Rust binary (no C dependencies, no glibc floor), so it runs on every distro and every arch we ship (x86_64 and aarch64). X11 users now install nothing for Computer Use, mirroring how KDE Plasma Wayland already relies on the bundled kwin-portal-bridge. Wayland-native sessions are unchanged: ydotool plus grim / gnome-screenshot / portal + PipeWire remain required for wlroots (Sway/Hyprland/Niri) and GNOME. The bridge lives in its own repo (github.com/patrickjaja/x11-bridge) and CI builds both arches from source and bundles them into the tarball.

Computer Use: v1.18286 handler realignment and Cowork gate fix

Several Computer Use fixes landed for the v1.18286 bundle:

• The chicagoEnabled gate that had disabled Computer Use inside Cowork sessions was corrected, so CU is available in Cowork again.
• The Linux CU handler was realigned to v1.18286's schema changes: the zoom region format, computer_batch image handling, coordinate scaling, and teach-mode anchor mapping.
• open_application now activates an already-open window (via the bridge) instead of only launching a new instance.
• request_access de-duplicates grants so repeated access requests no longer stack.

Launcher: --1p / --3p deployment-mode selector (upstream removed --boot-1p-once)

The upstream one-shot flag --boot-1p-once (MSIX-era) is no longer read by the official .deb bundle - the only remaining user-side switch is the persisted deploymentMode key in ~/.config/Claude-3p/claude_desktop_config.json. The launcher now offers claude-desktop --1p / --3p to write that key before launch (per-profile aware; persistent until switched back), and passing the removed --boot-1p-once exits with a pointer to the new flags. Root cause worth knowing: after deleting managed-settings.json the app can still boot 3P because the applied local-settings entry in ~/.config/Claude-3p/configLibrary/ (written by the in-app 3P Setup UI) also carries the inference provider - docs/third-party-inference.md's gotchas section was rewritten to describe the real config-source chain and the exit paths.

Computer Use: recognize Niri (issue #181)

The Linux executor's wlroots detection only checked SWAYSOCK and HYPRLAND_INSTANCE_SIGNATURE, so on Niri the grim screenshot path was never tried even with grim installed - Computer Use screenshots failed. _isWlroots() now also checks NIRI_SOCKET (Niri speaks the same wlr-screencopy protocol grim uses). The same gap existed in Wayland window discovery: getFrontmostApp and listRunningApps only had Hyprland/Sway backends; both gained a Niri backend via niri msg --json focused-window / windows. Startup diagnostics now list niri as a relevant tool on Niri sessions. Docs updated to include Niri in the Wayland session matrix.

Links

• AUR Package
• Full Changelog