[FEATURE] Official Claude Desktop build for Linux (Ubuntu LTS / Debian)
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
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
- 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.
- I develop Claude Code plugins. Plugins are tested and iterated on as Claude Desktop extensions, which requires Claude Desktop. There is no Linux build.
- 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.
- 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.
- Volume does not justify the engineering tax. Cowork parity, Windows hardening and agent capability work all plausibly outrank a third desktop platform.
- 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).
- Enterprise Linux developers are largely served by remote development and the CLI. A desktop GUI may not unlock enterprise revenue proportionate to its cost.
- Opportunity cost. Every engineer-quarter on Linux desktop is a quarter not on agent quality, MCP ecosystem, Cowork hardening, or enterprise control planes.
- 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.
51 Comments
Yes please. Then I can stop using unofficial builds that are reverse-engineered from the windows electron app.
please🙏🙏🙏🙏
i would like to have arch linux build too
yes, please.
Agreed. Linux desktop build for Linux please. Ubuntu LTS preferred if possible. Thank you.
Does anyone actually use the desktop app? O_o What's its utility?
I find it way easier to manage multiple coding sessions w/ the desktop app versus in the terminal.
I believe if you want to add local MCP servers to Claude the only option is the desktop app (via
~/.config/Claude/claude_desktop_config.json)?yes please
Pls do this!
As a long time Microsoft fan boy, Claude Code is the reason I left Windows behind and switched entirely over to Linux late last year!
Agreed!
Extremely necessary for some users
I want to see it on Fedora Linux too.
This is incredibly important for many of us, please add Fedora support.
Hi, Felix from Anthropic here!
Let me answer a understandable question first: Armed with Claude and developers with a history of shipping Linux software, why didn't we just churn out a quick Linux build? Historically, I've been cautious about building apps for Linux too early in the development cycle or haphazardly - a few of us are Electron maintainers and have spent years working both on apps and platforms for Linux, but actually supporting users on the heterogenous landscape that is Linux on the desktop isn't something I want to take lightly. There are plenty of reasons for that - drivers of varying quality, philosophical differences in window/package/service management, or sometimes undocumented differences between implementations lower in the stack, just to name a few. In other words, when we do ship a Linux build, I want to make sure it's actually good.
That said, we've grown a lot - as a team, as a community, and in how much we can lean on Claude. Feedback and issues like these are incredibly useful.
We don't have anything to share _right now_ but we hear the request for a Claude for Linux not just here, but from friends, too. We're grateful that you want to use Claude and do want to support as many of you as possible.
Thank you!
@powell-clark
we have also built such a project, its working very good on different linux versions🤞
all features supported, we are trying to stay rolling
https://github.com/patrickjaja/claude-desktop-bin
This would be great! Off and on Fedora user here.
No, you could have MCPs in the TUI.
I am bit curious why Linux is so poorly supported from Anthropics side, both desktop and cowork would be welcome here. And to be honest, if you don't fix it, others will!
I would take half the pay of any developer at anthropic to work on this tbh.
100% please
yes please
Why dont you just use Claude code to make the Linux build that solves all of your concerns?
Sounds like a skill issue tbh
If only they had a good llm to support this build!
Please do it
No, please don't. Noone needs it. What we actually need is cheap programmatic usage, which Anthropic decided to disable for everyone.
what are the solutions / alternatives that linux users are using in place of the codex desktop app ? im having trouble with the wsl2 method.
❤️ ➕ Plus one to this.
jfwiw, my current workaround to run Claude Desktop on Fedora: claude-desktop-rpm .
👏
Why not MacOS buddy? Macbook is cheaper than the equivalent Windows/Linux laptops.
I tried... At the end I switched back to my linux, I trully prefere gnome over osx in many levels, but that's not really the topic here
They can get Mythos to do almost all the work for them at this point, no excuses really.
+1 from a non-developer professional user on Ubuntu (Leuven, Belgium).
I use Claude daily for structured work: facility management documentation, HR appraisal cycles, pension modelling, and connected integrations with Gmail, Google Drive, and Google Calendar. Not a developer. Not a sysadmin. A knowledge worker who chose Claude as a serious productivity tool.
I'm currently running claude.ai in a browser tab alongside Claude Code CLI in a terminal, two surfaces, two contexts, no unified workspace. That's the workaround. It works, but it's friction that macOS and Windows users don't have to deal with.
What makes this hard to accept isn't the absence, it's the architecture. Reverse-engineering on Cowork's launch day confirmed that on macOS, Cowork boots a custom Ubuntu 22.04 VM. The Linux execution path already exists inside the product. The barrier is a platform detection check in an Electron app. The community proved it: johnzfitch/claude-cowork-linux runs Cowork natively on Linux x86_64 with no VM, no KVM, no QEMU, just stubbed macOS modules and a path translation layer.
I'm currently using aaddrick/claude-desktop-debian because I want one app, not two surfaces. A community maintainer is doing the work Anthropic hasn't prioritised. That's not a complaint about the maintainer, it's a signal about the gap.
What this issue is asking for is reasonable: a public position. "Planned for Q3" or "not on the roadmap because X", either is better than silence. The silence is what makes this feel like an oversight rather than a decision.
For what it's worth: I'm a paying subscriber. The product earns it. Linux desktop support would make it complete.
please🙏
+1.
When so many devs utilizing Linux for their development needs, it only makes sense to distribute developer tools to the audience through its natural channels!
Anthropic, come on!
It is very necessary
I'm also waiting for Claude Desktop on Linux, I don't why this problem to port it to Linux.
This could probably be one of the most upvoted issues here, if similar Linux requests had not been repeatedly closed, marked stale, or quietly redirected.
Anthropic presents Claude Code as a serious tool for developers, yet Linux, the most used desktop among developers, is still treated like an afterthought.
The “Linux support is hard” argument is difficult to take seriously when unofficial opensource repackages are maintained by one-person projects in their spare time, basically out of goodwill. If they can make it work, the absence of an official build looks more like a product decision than a technical limitation.
For companies that market themselves as concerned with reducing inequality and making powerful tools broadly accessible, this apparently does not seem to matter much when it comes to their own products.
Linux users should remember this when choosing products, especially when there are open source alternatives with stable Linux support maintained by teams infinitely smaller than Anthropic.
It is a shame that such an innovative company ends up pushing users toward alternatives because of decisions like this.
+++
really waiting for it!
+1
+++
The irony is real
Independent reverse-engineering found that on macOS, Cowork boots a custom Ubuntu 22.04 VM via Apple’s Virtualization Framework and runs the Claude Code binary inside it. Anthropic’s own agent runtime literally depends on Linux inside the product — they’re just not shipping it as a first-class platform. 
Anthropic already builds, signs, and distributes Linux software — Claude Code ships signed apt, dnf, and apk repositories with per-architecture binaries for linux-x64 and linux-arm64. The pipeline already exists.
The business reality
Anthropic has a $30B Azure compute commitment and a deep Microsoft partnership, with Claude reportedly turned on by default for most Microsoft 365 Copilot customers. Cowork was architecturally designed around Apple’s Virtualization Framework — macOS-first by design, not by accident.  The incentives are clearly tilted toward macOS/Windows.
PS - got this from opus 😄 and I'm paying for max plan which is still incomplete without Linux support.
The first AI company to ship official, fully supported Linux desktop tools will take the entire Linux user base.
We are not a large group, but we are the most valuable for training AI models.
We don't use AI to generate sharks wearing sneakers or as a replacement for therapy.
We are developers, sysadmins, and researchers — the people who generate the highest-quality, most technically demanding use cases.
Right now, Linux users are stuck with unofficial community repacks, no vendor support, and real security trade-offs.
That is a gap your competitors can exploit. First mover gets loyalty that is very hard to reverse in this community.
It happened with printing 22 years ago and HP took the advance and created HPLIP. I have HP from 2008 because of that.
So Fix it.
I'm waiting for it, too. If supporting different distributions is a problem, just support one or two mainstream distributions, e.g. Ubuntu, and then let hackers like aaddrick figure out the adaptation for others. For me, lacking Linux support is the main reason right now not to get an Anthropic subscription.
Hey folks, As of this morning Claude Desktop for Linux is officially in Beta.
https://x.com/ClaudeDevs/status/2071988881717871065
https://claude.com/download
Adding a Fedora/RHEL data point, since this issue's proposed solution (Ubuntu LTS + Debian via apt) wouldn't cover us.
I run Claude Code CLI natively on Fedora Workstation daily — it's solid. The gap I actually feel is Cowork specifically, not general desktop parity: Dispatch-from-phone and scheduled agentic tasks against local files have no CLI equivalent, and that's a different capability, not just a GUI wrapper on what the CLI already does.
For Fedora/RHEL there's no first-party path at all right now — not even a community apt-equivalent as polished as aaddrick's Debian build, though a couple of RPM ports exist (christian-korneck/claude-desktop-rpm, bsneed/claude-desktop-fedora). If a Debian-first rollout is the realistic near-term plan, it'd help to know whether RPM (dnf) is even on the eventual roadmap or a "maybe later" — happy to test on Fedora if that'd help derisk it.
@ncancelliere it is planned:
Thank you @felixrieseberg and the team! 🙌🏼🙏🏾🙇🏾♂️