[FEATURE] Official Claude Desktop build for Linux (Ubuntu LTS / Debian) · Issue #65697 · anthropics/claude-code · GitHub

Preflight Checklist

Problem Statement

Preflight note. The closest open issue is #40347. Related: #47316 (closed), #38276 (closed as out of scope for this repo), #36011 (stale). I am filing this as a consolidation and extension of #40347 with corrected technical framing (Claude Code plugin development against Desktop extensions), named primary sourcing for the Cowork Linux-VM architecture, and current market data. Happy to merge into #40347 if maintainers prefer; please route rather than close if a different venue is correct.

On scope: this issue concerns Claude Code in two concrete ways. (1) Claude Code plugins are developed and tested against Claude Desktop extensions, which has no Linux build, so plugin work currently requires switching OS. (2) Cowork invokes the Claude Code binary inside a Linux VM on macOS, so the Linux execution path already exists inside the Claude Code product and is the practical thing missing as a published target.

What this issue is asking for
A public Anthropic position on Linux desktop support, and ideally a first-party build. A reasoned “not on the current roadmap, and here is why” would resolve most of what this issue is about. There is, to my knowledge, no public statement on Linux desktop support; the absence is itself part of the problem.

Current state

Anthropic distributes Claude Desktop for macOS and Windows only. The official download page states “Not available for Linux”. Claude Code (the CLI) runs natively on Linux but is a terminal tool, not a substitute for the desktop GUI. Desktop extensions (the surface Claude Code plugins are tested against), computer use, desktop dictation and Cowork are available only in Claude Desktop. Linux users therefore have no officially supported graphical path to these capabilities, and in particular no way to develop and test Claude Code plugins as desktop extensions without switching to macOS or Windows.

Why this is structurally hard to justify
Anthropic already builds, signs and distributes Linux software. Per code.claude.com/docs/en/setup, Claude Code ships signed apt, dnf and apk repositories and per-architecture binaries (linux-x64, linux-arm64, musl variants). The pipeline exists.

The Cowork agent already depends on Linux inside the product. Independent reverse-engineering by Simon Willison on launch day (12/01/2026), corroborated by Pluto Security and pvieito (“Inside Claude Cowork”), found that on macOS Cowork boots a custom Ubuntu 22.04 VM via Apple’s Virtualization Framework (VZVirtualMachine) and runs the Claude Code binary inside it under bubblewrap and seccomp. Anthropic’s own documentation confirms the hypervisor split: Apple Virtualization.framework on macOS, Hyper-V on Windows. The community project johnzfitch/claude-cowork-linux demonstrates the same Cowork mode running natively on Linux x86_64 by stubbing the macOS native modules and skipping the VM entirely. The Linux capability already exists inside the product; what’s missing is a published Linux target.

Why it matters that it is missing
Claude Desktop handles OAuth tokens, API keys, and extension configurations. It is a credential-handling application running on developer workstations.

Linux users currently obtain it via third-party repackages of the Windows Electron build. The leading project, aaddrick/claude-desktop-debian (roughly 4.5k stars), is genuinely high quality: signed apt and dnf repositories, .deb/.rpm/AppImage/AUR/Nix builds, CI-tested, a –doctor diagnostic, and upstream tracking within days (latest release 05/06/2026, tracking Claude Desktop 1.11187.1). It is also, by definition, not vendor-signed and not vendor-audited. A non-trivial number of Claude users entrust their credentials and local filesystem access to a third-party repackage because Anthropic ships nothing official. The structural risk is not about the current maintainers; it is the precedent on a platform Anthropic’s own agent runtime depends on.

Linux is not a fringe developer platform. Stack Overflow 2025 (49,000+ respondents, 177 countries): Ubuntu primary OS for 27.7% of professional developers. StatCounter: India desktop Linux 16.21% (July 2024); US crossed 5% in June 2025.

Proposed Solution

Publish an official Claude Desktop build for Linux, targeting the two current Ubuntu LTS releases (and Debian) as a signed .deb via an Anthropic-operated apt repository, using the same distribution pipeline Claude Code already uses for Linux.

Alternative Solutions

Claude Code CLI: official and runs natively on Linux with signed apt/dnf/apk repositories. Excellent for terminal workflows and runs local MCP servers fine. Not a substitute for the desktop GUI: no surface for testing Claude Code plugins as desktop extensions, no computer use, no Cowork.

Web client (claude.ai): supports remote MCP connectors but no desktop extensions, no computer use, no Cowork. Loses conversation state on browser crash; higher RAM and battery cost than a native client.

Community repackages (aaddrick/claude-desktop-debian, johnzfitch/claude-cowork-linux, Snap wrappers, k3d3 NixOS flake): functional and what I currently use. Unofficial, not vendor-signed, not vendor-audited.

Windows build under Wine: clipboard and font integration break, MCP subprocess handling is unreliable, no first-party security updates.

Switching to macOS or Windows to test plugins: current workaround. Friction on every iteration; not a real fix.

Priority

High – Significant impact on productivity

Feature Category

Developer tools/SDK

Use Case Example

1. I run Ubuntu LTS as my primary development environment. Per the Stack Overflow 2025 Developer Survey, this is the case for 27.7% of professional developers.

2. I develop Claude Code plugins. Plugins are tested and iterated on as Claude Desktop extensions, which requires Claude Desktop. There is no Linux build.

3. The current workaround is to switch to macOS every time I need to test a plugin as an extension. This is friction on every iteration of a plugin I am building on Linux, and a sufficiently bad ergonomic that it discourages plugin development from Linux entirely.

4. With an official Linux build I would install via apt from an Anthropic-signed repository and develop, test and iterate on Claude Code plugins as desktop extensions on the same machine I write them on.

Additional Context

Sources for the load-bearing claims, named primary where possible.

Platform support matrix

• claude.com/download: “Not available for Linux”.
• code.claude.com/docs/en/desktop: desktop app available for macOS and Windows.

Claude Code already on Linux

• code.claude.com/docs/en/setup: signed apt, dnf and apk repositories; per-platform binaries (linux-x64, linux-arm64, linux-x64-musl, linux-arm64-musl); Ubuntu 20.04+/Debian 10+.

Cowork Linux-VM architecture

• Simon Willison, “First impressions of Claude Cowork”, 12/01/2026 (simonwillison.net): VZVirtualMachine via Apple’s Virtualization Framework booting a custom Linux root filesystem.

• Pluto Security: corroborating reverse-engineering deep dive, Ubuntu 22.04 inside the VM.

• pvieito, “Inside Claude Cowork”: macOS host → Apple Virtualization Framework → Ubuntu 22.04 VM → bubblewrap → seccomp → Claude Code at /usr/local/bin/claude.

• Anthropic documentation confirms the hypervisor split (Apple Virtualization.framework on macOS, Hyper-V on Windows) without confirming the reverse-engineered internals.

• johnzfitch/claude-cowork-linux: working community port that stubs the macOS native modules and runs Cowork directly on Linux x86_64 with no VM.

Community packaging

• aaddrick/claude-desktop-debian: roughly 4.5k stars; .deb, .rpm, AppImage, AUR, Nix; signed apt and dnf repositories at pkg.claude-desktop-debian.dev; latest release v2.0.18+claude1.11187.1 dated 05/06/2026; –doctor diagnostic; CI-tested; experimental Cowork on Linux.

• Related: aaddrick/claude-desktop-arch, emsi/claude-desktop, k3d3/claude-desktop-linux-flake.

Demand

• StatCounter: India desktop Linux 16.21% (July 2024); US crossed 5% in June 2025; global approximately 4.7% in 2025.

If a first-party build is not on the roadmap

A lower-cost fallback that would address most of the trust and security concerns: a public statement on the install documentation that Linux is not currently planned (with rough horizon if any), acknowledgement of a recommended community project, a one-off security review summary of that project, and explicit security guidance for Linux users on credential handling and MCP server configuration.

Steelmanned counter-case

The strongest internal “not now”, so this issue invites a real conversation rather than a polite close.

1. Volume does not justify the engineering tax. Cowork parity, Windows hardening and agent capability work all plausibly outrank a third desktop platform.

2. Linux fragmentation creates a disproportionate support tax: distros, display servers, sandboxing models, graphics stacks. The community project’s commit log shows the surface (AppArmor userns blocks, KDE Plasma SNI races, Wayland HiDPI, eCryptfs path-length failures).

3. Enterprise Linux developers are largely served by remote development and the CLI. A desktop GUI may not unlock enterprise revenue proportionate to its cost.

4. Opportunity cost. Every engineer-quarter on Linux desktop is a quarter not on agent quality, MCP ecosystem, Cowork hardening, or enterprise control planes.

5. Distribution is non-trivial. Signed repos, GPG keys, AppImage signing, Snap, AUR, Nix.

A reasonable senior decision could weigh these and conclude “not on the current roadmap”. I would understand that. What I do not understand is the absence of any public position at all, and the structural security cost of that silence to current Linux users.

Note on the triage bot

I am aware this issue is processed by an automated triage system. I have written it as a single consolidated request with a clear primary ask and a lower-cost fallback (the “good no” path in Additional Context). Please route rather than close if a different venue is correct; please respond rather than close as “not planned” without a stated rationale, because the absence of a stated rationale is part of what this issue is asking to fix.

Happy to contribute and help maintain.