Claude Desktop on Arch Linux: the AUR package, or open source

Anthropic publishes one package, and it is a .deb

"Claude Desktop for Linux is in beta and supports Ubuntu and Debian (x64 and arm64)." The requirements page adds the sentence that decides the route: "On distributions that aren't Debian-based, such as Fedora or Arch, run the CLI instead." (Anthropic's Linux docs)

Every route here bends around that second sentence. Anthropic builds the app once and ships it as a .deb from its own apt repository under the package name claude-desktop (check the download page). Outside Debian, someone repackages those bytes for your distribution, adds a launcher, and publishes the result. The repackaging project says it plainly: "Anthropic serves the .deb. We serve everything else." Debian readers have the shorter path, the apt install on Ubuntu and Debian.

So the decision turns on three things: who rebuilds when Anthropic ships a new version, how that rebuild reaches you, and what the builder changed on the way. Three projects answer those questions differently, and one of them stopped publishing to the AUR in August 2026.

Arch: a package in the AUR, maintained by one person

The repackaging project's format table puts AUR in the "Not this project" row, and its readme sends Arch readers to the AUR package instead. claude-desktop is a community package of Anthropic's .deb, maintained by diazkev314, at version 3.6556.2-1 and last updated 2026-10-23 (AUR entry). It carries no launcher and no --doctor, because those belong to the other project.

Start with the dependency list. edk2-ovmf and bubblewrap sit among the 47 dependencies, next to the GTK, PipeWire and X11 libraries the Electron app links against. edk2-ovmf is the UEFI firmware Cowork's virtual machine boots, so the package expects Cowork to run rather than treating it as an extra.

Updates arrive when the maintainer rebuilds. The AUR entry has no repository of its own and no timer, so your helper sees a new pkgver after the maintainer pushes one, and the gap between Anthropic's release and yours is that person's turnaround. A quiet month upstream is a quiet month on Arch, which is fine until Anthropic ships a security release.

Arch readers have a second option in the other project's AppImage, which carries the launcher and --doctor. That project used to publish claude-desktop-appimage to the AUR and deleted it on 2026-08-01 as a duplicate of claude-desktop, so an old installation of it no longer receives updates and should be removed.

Fedora and RHEL: a repository, or a script that checks signatures

Two routes ship the same app with different trust shapes. The repackaging project publishes .rpm packages from its own dnf repository, installed as claude-desktop-unofficial and updated with dnf upgrade. That is the ordinary Fedora experience: root, system paths, and a third-party repository you add once.

The other comes from ajithakdev/claude-desktop-rpm, an MIT-licensed script that "installs the official package into ~/.local without root, verifies Anthropic's signing key, the signed repository index and the package checksums, and updates through a systemd user timer" (Fedora Discussion). It was tested on Fedora 44 Workstation x86_64, and it redistributes nothing: the script downloads from Anthropic and checks the chain before installing.

The discussion thread is the maintenance signal worth reading. A reader found the repository index could be signed by any key in the key bundle rather than the pinned one, and the maintainer fixed the check, added tests and shipped a corrected release. A later report found the Cowork step replacing two OVMF links that Fedora's edk2-ovmf ships; that was reverted, and nothing under /usr is touched now. A script that answers a bug report in public, with a test attached, is a different dependency from a repository nobody has audited.

Read the optional Cowork step before you run it. It writes /etc/modules-load.d/vhost_vsock.conf, loads vhost_vsock and adds your account to the kvm group, which are the host requirements Anthropic documents. Skip the step and you get the app without Cowork.

openSUSE: the AppImage, since no package names it

Neither Anthropic's .deb nor the project's .rpm targets openSUSE: the format table names Fedora and RHEL for the rpm. The route that fits is the AppImage, which the project calls distribution-agnostic and which carries the launcher and the --doctor checks.

Updates are manual, and that is the trade. There is no repository entry and no timer, so you download the next release and replace the file. That build is also where the launcher's own options live, including the Wayland switch CLAUDE_USE_WAYLAND=1 and its GPU-crash recovery.

NixOS: a flake you pin

NixOS gets a flake from the same project. Install it into a profile with nix profile install github:aaddrick/claude-desktop-debian, or add the overlay to configuration.nix and put pkgs.claude-desktop in environment.systemPackages. The #claude-desktop-fhs output wraps the app for MCP servers that expect a conventional filesystem layout.

Updates follow Nix's model rather than an app's. The input is pinned in flake.lock, a rebuild keeps the version you pinned, and nix flake update moves it when you decide. A bad update rolls back to the previous generation, which the other routes here don't give you.

One config directory, two packages

This is the detail that catches people. The project names its packages claude-desktop-unofficial so they install beside Anthropic's claude-desktop instead of colliding with it. Both then write to ~/.config/Claude, so only one can run at a time (project readme).

Side by side means two packages and one set of files. MCP servers live in ~/.config/Claude/claude_desktop_config.json for both builds, so a server you add in one appears in the other, and sign-in state shares the directory too. If an official package and an unofficial build end up on the same machine, uninstall one before starting the other, and let --doctor report name collisions.

On Arch, pacman does part of that work: the AUR entry declares conflicts with claude and claude-desktop-bin.

What no route changes about Cowork

Cowork is where packaging stops mattering. On Linux the app runs Cowork's tasks in a virtual machine it hosts with QEMU and KVM, and that requirement belongs to Anthropic's code rather than to the wrapper. The project states the limit in its own readme: "Cowork on Linux: runs when KVM (hardware virtualization) is available."

The host still needs firmware virtualization turned on, /dev/kvm, /dev/vhost-vsock, membership in the kvm group, and qemu-system-x86, ovmf and virtiofsd on x86_64, or the arm64 equivalents. Repackaging removes two packaging-level obstacles, and neither of them is a missing device. The project patches virtiofsd resolution, because Arch installs it at /usr/lib/virtiofsd and Debian at /usr/lib/qemu/virtiofsd while upstream probes two other paths, so a complete KVM stack stops reporting "requires QEMU". It also adds the firmware compatibility symlink the rpm path needs. Without /dev/kvm, no patch helps.

Start with the devices, before the package:

grep -cE 'vmx|svm' /proc/cpuinfols -l /dev/kvm /dev/vhost-vsockid -nG | grep -w kvm

Zero from the first line means firmware virtualization is off, and nothing you install changes that. A missing /dev/vhost-vsock with no module directory under /lib/modules means the kernel lacks the support Cowork needs. Join the group with sudo usermod -aG kvm $USER, log out and back in, then restart the app, because it checks the requirements once at launch. The Cowork error page takes each message in turn.

The bubblewrap backend, and what it does not do

The project also ships an opt-in path for hosts without KVM: "Cowork bubblewrap backend. Opt-in via COWORK_VM_BACKEND=bwrap for hosts without KVM/vhost-vsock. Every branch is gated on the flag, so an unflagged launch runs upstream's path unchanged." Its docs index calls the earlier bwrap daemon "superseded on KVM hosts" and parks it under scripts/cowork-fallback/.

Two limits are worth stating before you lean on it. The sandbox boundary changes mechanism: a bubblewrap sandbox on your own kernel instead of a virtual machine the app boots, so the isolation you get is the one bubblewrap provides rather than the one Anthropic documents. And the flag is a switch, not a fallback that engages itself. Launch without COWORK_VM_BACKEND=bwrap and you are on the upstream path again, with the error you started from.

The flag also lives in this project's builds. The AUR package and the Fedora script are separate packagings, so whether either carries the switch is its packager's call, and it is worth checking before you plan around it.

Choosing between them

Who rebuilds when Anthropic ships? A single AUR maintainer, a dnf repository, a systemd timer on your own machine, or a flake input you update yourself. Pick the one whose silence you would notice.

Which checks come with the build? The project's formats carry the launcher, --doctor and the virtiofsd and firmware patches. The AUR package carries none of them. The Fedora script keeps its own claude-desktop-rpm doctor and verifies signatures instead.

Can the machine host the virtual machine at all? If it can, every route here ends in the same working app, so pick on maintenance cost. If it cannot, the bwrap flag or a different computer is the real decision.

When the machine is the blocker

All of these routes assume a distribution with a package and a host that can carry a virtual machine. Where either one fails, Kortix is the route that skips the package. Run it on Kortix Cloud, in your VPC, or on your own on-prem network. Self-host is free.

The laptop then needs a browser tab or the CLI, and the kernel stops being part of the question. How an agent runs on Linux walks through that setup, and the home page carries the support picture for every distribution.