[FEATURE] Anfrage nach einem offiziellen Linux-Build (Ubuntu LTS/Debian) für Claude Desktop

• Öffentliche Stellungnahme von Anthropic zur Unterstützung von Linux-Desktops und, wenn möglich, die Bitte um einen ersten offiziellen Claude-Desktop-Build für Ubuntu LTS/Debian
• Claude Desktop wird derzeit nur für macOS und Windows verteilt; auf der offiziellen Download-Seite steht "Not available for Linux", sodass Linux-Nutzer Desktop extensions, computer use, desktop dictation und Cowork nicht über einen offiziellen GUI-Weg verwenden können
• Claude Code CLI läuft nativ unter Linux, ist aber ein Terminal-Tool und daher kein Ersatz zum Entwickeln und Testen von Claude-Code-Plugins als Claude Desktop extensions; aktuell erfordert das Testen von Plugins den Wechsel zu macOS oder Windows
• Claude Code bietet bereits signierte apt-, dnf- und apk-Repos sowie Binärdateien für linux-x64, linux-arm64 und musl-Varianten; die vorgeschlagene Lösung ist die Bereitstellung eines signierten .deb aus einem von Anthropic betriebenen apt-Repository über dieselbe Distributions-Pipeline
• Als Grundlage zu Cowork werden Reverse-Engineering-Ergebnisse von Simon Willison, Pluto Security und pvieito zitiert; zusätzlich wird erklärt, dass die Claude-Code-Binärdatei unter macOS in einer Ubuntu-22.04-VM auf Basis des Apple Virtualization Framework läuft, zusammen mit dem Hinweis auf die in der Anthropic-Dokumentation bestätigte Trennung der Hypervisoren für macOS und Windows
• johnzfitch/claude-cowork-linux wird als Community-Port vorgestellt, der macOS-native Modules stubbt und den Cowork-Modus ohne VM auf Linux x86_64 ausführt
• Linux-Nutzer sind derzeit auf Repackaging durch Dritte des Windows-Electron-Builds angewiesen; aaddrick/claude-desktop-debian bietet signierte apt-/dnf-Repos, .deb, .rpm, AppImage, AUR-, Nix-Builds, --doctor, CI-Tests und Tracking-Releases für Claude Desktop 1.11187.1, ist aber nicht vendor-signed und nicht vendor-audited
• Da Claude Desktop als Anwendung zur Verarbeitung von Zugangsdaten auf Entwickler-Workstations mit OAuth tokens, API keys und extension configurations umgeht, führt das Fehlen eines offiziellen Linux-Builds zu Vertrauens- und Sicherheitsbedenken
• Als Alternativen werden Claude Code CLI, der Web-Client claude.ai, Community-Repackages, Ausführung über Wine und der Wechsel zu macOS/Windows aufgeführt; für alle werden jedoch Einschränkungen bei desktop extensions, computer use, Cowork, Integrationsstabilität, primären Sicherheitsupdates und wiederkehrender Reibung in der Entwicklung genannt
• Falls ein erster Build nicht auf der Roadmap steht, wird als Fallback gefordert, in der Installationsdokumentation den ungeplanten Linux-Status und einen groben Zeitrahmen offenzulegen, empfohlene Community-Projekte anzuerkennen, eine einmalige Zusammenfassung einer Sicherheitsprüfung zu veröffentlichen und Sicherheitsrichtlinien für credential handling und MCP server configuration unter Linux bereitzustellen

[GN⁺]

Hacker-News-Kommentare

• Ein inoffizieller Build wird unter https://github.com/aaddrick/claude-desktop-debian gepflegt
  Zwar steht Debian im Namen, aber der Umfang hat sich inzwischen auf alle möglichen Backends, Compositoren usw. ausgeweitet, und der Hauptgrund, warum Firmen nur selten Electron-Apps für Linux veröffentlichen, scheint mir die Fragmentierung der Distributionen zu sein
  Sobald man über das bloße Rendern einer Webseite als App hinausgeht, wird es schnell komplex, und selbst mit einem Bündel an Test-VMs bleibt der Bedarf dauerhaft bestehen

  • In einer früheren Firma habe ich trotz einer geringen Zahl interessierter Kunden ernsthaft daran gearbeitet, einen Linux-Desktop-Client herauszubringen, und dabei festgestellt, dass man sehr schnell in der Kompatibilitätshölle landet
    Man denkt vielleicht, ein paar aktuelle Ubuntu-Versionen als Ziel würden reichen, aber dann hagelt es Beschwerden, dass irgendein Teil der App auf einer Distribution nicht funktioniert, von der man noch nie gehört hat
    Selbst wenn ein Engineer einen halben Tag darauf verwendet, sie in einer VM zu installieren und zu debuggen, liegt die Ursache oft irgendwo in einem Upstream-Projekt, und Linux-Issue-Tickets häufen sich weiter an – für eine Kundenzahl, die zu klein ist, um das zu rechtfertigen
    Und diese Kunden sind dann wütend und laut. Sie erwähnen nicht, dass sie auf einem 13 Jahre alten ThinkPad eine obskure Distribution fahren, sondern posten auf Twitter, Hacker News und Reddit, dass die Software der Firma Schrott ist
    Selbst Open-Source-Electron-Apps laufen auf mehreren populären Distributionen nicht ohne Kommandozeilen-Workarounds, und oft auch dann nur instabil. Bei Open Source nimmt man das hin, aber wenn eine Firma etwas ausliefert, kann sie sich dadurch ungewollt eine Menge verärgerter Kunden einhandeln
  • Die Aussage, Firmen würden keine Electron-Apps für Linux veröffentlichen, ist etwas seltsam. Eher scheint es so, als würden Firmen fast nur Electron-Apps veröffentlichen
    Wenn Desktop-Linux außerhalb von Freier/Open-Source-Software überhaupt etwas bekommt, dann meist Electron, und Beispiele wie Spotify, Discord, Slack, VSCode setzen sich immer weiter fort
    Mir fällt aus den letzten 20 Jahren kaum ein Fall ein, in dem ein gewinnorientiertes Unternehmen eine ordentliche GTK- oder Qt-App für Linux bereitgestellt hätte
    Die inoffiziellen Build-Bemühungen sind großartig, aber bei einem Produkt eines Unternehmens mit vermutlich Billionenbewertung, dessen Trainingsdaten wohl Tausende Electron-Apps enthalten haben dürften, sollte das Unternehmen die Kosten selbst tragen
  • Könnte Flatpak nicht einen großen Teil dieser Probleme lösen? Man könnte die App für genau einen Window-Manager bzw. eine Desktop-Umgebung entwickeln und das dann einfach als Flatpak-Anforderung festlegen
  • Für Codex Desktop gibt es ein ähnliches Projekt: https://github.com/ilysenko/codex-desktop-linux
    Nachdem ich den Installationsprozess für codex unter Linux durchlaufen habe, verstehe ich wirklich nicht, warum OpenAI keinen offiziellen Port veröffentlicht
    Ich habe nicht jeden Teil der App getestet, aber es funktionierte wie beabsichtigt, und auch computer use lief problemlos

• Es wäre schön gewesen, wenn Anthropic so etwas wie Automatisierungstools hätte, die gut darin sind, Software zu portieren

  • Auch wenn man unbegrenzt Software bauen könnte, müsste man immer noch sehr bewusst auswählen, woran man arbeitet
    Selbst wenn Coding jetzt „kostenlos“ wäre, bleiben Kosten für Tests, Support und Planung bestehen
  • Es klingt nicht so, als läge dort der Engpass
  • Da fehlt noch allegedly
  • Es wäre schön, wenn führende KI-Unternehmen beschließen würden, mit der besten KI der Welt Software für Linux zu entwickeln und dafür sogar ordentlichen Support anzubieten
  • Soll damit etwa noch schlechtere Linux-Apps mit dem bestehenden schlampigen Kram gebaut werden, der für eine simple Terminal-App 1 GB RAM braucht?
    Es wäre schön, wenn unter den Entwicklern mit Vergütungspaketen über 500.000 Dollar jemand wäre, der eine einfache App ohne Macken so schreiben kann, dass man sie tatsächlich nutzen möchte

• Viele sagen, das sei ein schwieriges Problem, aber interessant ist, dass Discord Folgendes geschrieben hat
  „Bist du als Linux-Nutzer diesen liebenswerten Dialog leid, der dir sagt, dass es ein Update gibt und du es selbst installieren sollst? Dann haben wir gute Nachrichten. Wir haben unseren Rust-basierten Updater auf Linux portiert, sodass Linux sich jetzt wie Windows selbst aktualisieren kann. Außerdem unterstützen wir nun die Installationspaketformate .rpm und .pkg.tar.zst.“
  Discord ist eher ein noch anspruchsvollerer Client, weil dort Bildschirmaufnahme, Audioaufnahme und Audio-Routing behandelt werden müssen und außerdem drei Paket-Repositories unterstützt werden
  Wenn man die grundlegenden Probleme behebt, muss man nur akzeptieren, dass Build-/Runtime-Abhängigkeiten versionsweise aktualisiert werden müssen
  Dass ein einzelnes Binary verteilt wird und funktioniert, bedeutet eben, dass alle Bibliotheken, von denen dieses Binary abhängt, mitgeliefert werden müssen; Windows erledigt das mit winsxs, Linux verlangt, dass man es selbst macht

• Ich frage mich, was bei einer Desktop-App fehlt, was die CLI nicht leisten kann. Ich nutze selbst meist Linux und habe einfach die CLI verwendet

  • Beim Anthropic-Abo scheint die CLI die tägliche Routine nicht mehr anzubieten
    Außerdem verwendet die Erinnerungssuche über Gespräche hinweg einen anderen Datensatz als Claude Code, nämlich die Konversationen aus Claude Web/Claude.AI, und ich bin nicht einmal sicher, ob Claude Code überhaupt gesprächsübergreifend sucht
    Die Desktop-Oberfläche zeigt Markdown als formatierten Text an und stellt insbesondere interaktive Artefakte deutlich besser dar als die CLI
    Trotzdem nutze ich in der Praxis für fast alles die CLI. Die täglichen Routinen in Claude Desktop sind insgesamt auf 15 Cron-Jobs begrenzt und verbrauchen zusätzliche Nutzungsguthaben, deshalb plane ich, mir selbst ein minimales Harness zu bauen und die Routinen auf Modelle anderer Anbieter zu verlagern
  • Wenn man dieselbe Erfahrung wie nicht unter Linux arbeitende Kollegen nutzt, lassen sich Erkenntnisse und Prozesse leichter teilen
    Ich brauche auch lokal laufende geplante Aufgaben, und die Funktion unter https://support.claude.com/en/articles/13854387-schedule-rec... unterscheidet sich in wichtigen Punkten von den Routinen in Claude Code
    Ich brauche außerdem Funktionen zum Umgang mit mehreren Projekten/isolationierten Erinnerungen innerhalb desselben Ordners sowie eine bessere UI
  • Die Desktop-App ermöglicht es, über die Code-Funktionen eine geöffnete Remote-Session zu steuern
  • Ich möchte die Inline-Bilder sehen, die Claude mir plötzlich zeigen will. In der CLI macht es einfach immer weiter, bis es mich erneut darauf hinweist, dass ich dort keine Bilder sehen kann
    Davon abgesehen bin ich mit der CLI zufrieden
  • Für Coding-Aufgaben ist die CLI gut, aber für andere Dinge ohne Coding-Bezug kann die Desktop-App ziemlich nützlich sein

• Ich weiß nicht, wie groß der Markt an Linux-Nutzern ist, die in von Visual Studio abgeleiteten Apps Vibe-Coding mit einer Electron-App machen wollen, sie aber weder selbst bauen noch das Repository anderer klonen und kompilieren würden

  • Ich weiß es auch nicht genau, aber wenn man Claude Desktop auf einer Linux-Maschine nutzen könnte, würde ich diese Rolle sogar gerne für die Hälfte des Gehalts eines Anthropic-Entwicklers übernehmen
    Third-Party-Hacks, die eine Electron-App für Windows unter Linux zum Laufen bringen, fühlen sich für mich immer unerquicklich an, deshalb mag ich sie nicht
  • Ich habe persönlich kein direktes Interesse daran, weil ich die Claude-App nicht will, aber der durchschnittliche Linux-Nutzer von heute ist immer mehr einfach eine normale Person, die Dinge wie überwachungsartige Telemetrie oder Werbung nicht will

• Es überrascht mich, dass immer noch viele Entwickler die Nutzung von Linux geringschätzen
  Ihr benutzt doch schon Docker und deployt auf K8S. Und das auch noch auf Linux

  • Das Betriebssystem selbst ist mir ziemlich egal. Ich will einfach einen leistungsstarken Laptop mit guter Tastatur und gutem Trackpad, langer Akkulaufzeit und scharfem Display
    Wenn er dazu noch sehr leise ist und ein sauberes Design hat, umso besser. Das ist das Wertversprechen des MacBook
  • Das ist überhaupt nicht dasselbe
  • Desktop und Server haben einen völlig unterschiedlichen Support-Umfang

• Man kann es doch einfach in einem Rutsch selbst zusammen-viben
  Ist zwar albern, aber wenn hier alle nur noch von scharfem Autocomplete und selbstverschuldeter Arbeitsplatzvernichtung reden, muss man sich gelegentlich eben selbst amüsieren

  • Schön zu sehen, dass außer mir noch jemand auf dieser schrecklichen Seite die Perspektive der selbstverschuldeten Arbeitsplatzvernichtung sieht

• Ich verstehe persönlich nicht, warum es für Claude Code keinen Modus gibt, der den Text grün macht und die Zeichen wie in The Matrix einzeln von oben über den Bildschirm laufen lässt

  • Das ist extrem störend. Um heutzutage richtig zu arbeiten, muss man wohl eine grüne Sonnenbrille tragen, die Sprache auf Japanisch umstellen und den Monitor seitlich drehen

• Ich fände es gut, wenn man vorsichtig damit wäre, wie man die Anfrage formuliert
  Wenn das Ziel ist, Claude für Softwareentwicklung zu nutzen, wäre ich schon zufrieden, wenn die claude-CLI-Binärdatei alles Nötige innerhalb einer für die Arbeit eingerichteten Linux-KVM-VM-Sandbox erledigt und es keinen Desktop-Client gibt. Je sauberer und vertrauenswürdiger, desto besser
  Gewöhnliche interaktive Nutzung zum Stellen von Fragen sollte in der Browser-Sandbox des Host-Desktops stattfinden, und ich möchte, dass dieser Weg gut unterstützt wird
  Marketing- und Produktleute bei AI-Unternehmen wollen die Leute natürlich in proprietäre Desktop-Clients drängen, aber das ist immer noch ein Bereich möglichen Missbrauchs, den man im Zaum halten kann
  Agentische Automatisierung, die den Host-Desktop und alles, worauf er zugreifen kann, gleich mitbedient, lehne ich ab. Der Stand der Technik ist dafür noch nicht bereit

  • Das Problem ist, dass VNC im Vergleich zu RDP einfach viel zu schlecht ist
    Der Zugriff auf den GUI-Client in dieser VM ist miserabel, sonst würde ich den GUI-Client nicht so leicht ablehnen

• Es ist schon ironisch, dass Hunderte Nutzer CLI-Agenten verwenden und trotzdem keine Desktop-Version tatsächlich selbst bauen können
  Macht LLM die Menschen wirklich so hilflos?

  • Das war kurz nachdem Anthropic wegen claude -p so viel Aufhebens machte, um Openclaw zu blockieren, deshalb wollte ich mich lieber nicht in die Nachwirkungen hineinziehen lassen
    Es war schwer, den Schlagabtausch auf beiden Seiten zu verfolgen, aber inzwischen scheint es vielleicht vorbei zu sein
  • Für eine einzelne Person ist es schwer, bei einem Produkt mitzuhalten, das mehrmals täglich Updates herausbringt
  • Man sollte beachten, dass in der Anfrage das Wort offiziell vorkommt. Inoffizielle Versionen gibt es bereits