Anthropic,请发布官方的 Linux 版 Claude 桌面应用。
Anthropic, please ship an official Claude Desktop for Linux

原始链接: https://github.com/anthropics/claude-code/issues/65697

此请求旨在倡导官方推出 Linux 版 Claude 桌面应用,并强调目前缺乏官方支持的现状正迫使专业开发者依赖不安全的第三方社区重打包版本。 **Linux 支持的必要性:** * **技术就绪:** Anthropic 已为 Claude Code 维护了 Linux 存储库,并在“Cowork”智能体架构中使用 Linux 环境,原生 Linux 版本的相关基础设施已基本就绪。 * **开发者阻碍:** 插件开发需要在 Claude Desktop 扩展中进行测试。由于缺乏 Linux 图形界面,开发者被迫切换操作系统,这严重降低了生产力。 * **安全隐患:** 目前超过 27% 的专业开发者使用 Linux。由于缺乏官方渠道,用户常将敏感凭据和 API 密钥输入到非官方的社区构建版本中,带来了巨大的安全风险。 **建议:** 作者请求 Anthropic 提供官方签名版 Linux 安装包(如适用于 Ubuntu/Debian 的 `.deb` 文件)。考虑到资源可能有限,作者提出了一种“折中”方案:在产品路线图中发布官方声明、对主流社区项目进行安全审计或认可,并就如何安全处理凭据提供指导。作者敦促维护团队给予合理的回复,而非选择静默关闭请求。

Hacker News 用户正积极呼吁 Anthropic 发布官方 Linux 版 Claude 桌面应用。尽管目前已有社区维护的项目,但用户认为官方构建版本对于实现与 macOS/Windows 的功能对等至关重要,例如集成日常流程、跨对话记忆搜索以及更好的 Artifacts UI 渲染。 这场讨论突显了 Linux 社区在偏好上的分歧。许多高级用户依赖 Claude CLI,但也有人认为它缺乏桌面客户端所具备的沙盒安全性和界面优势。注重安全性的用户讨论了授予 AI 工具广泛文件系统访问权限的风险,并提议使用 Docker、`bwrap` 或 `jai` 等沙盒解决方案来降低这些风险。 总的来说,共识在于:由于 Anthropic 现有的内部基础设施已支持 Linux,公开版本是目前迫切需要补齐的短板。然而,怀疑论者仍对基于 Electron 的桌面应用所消耗的大量资源持保留态度,并质疑其相比现有的网页版或 CLI 替代方案,是否真的能提供足够的实用价值来抵消其带来的系统负担。
相关文章

原文

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.

联系我们 contact @ memedata.com