[FEATURE] Claude Desktop の公式 Linux（Ubuntu LTS/Debian）ビルドの要望

• Anthropic の Linux デスクトップ対応についての公式見解の公開と、可能であれば Ubuntu LTS/Debian 向けの初の公式 Claude Desktop ビルドを要望
• 現在 Claude Desktop は macOS と Windows 向けにのみ配布されており、公式ダウンロードページでは "Not available for Linux" と表示されているため、Linux ユーザーは Desktop extensions、computer use、desktop dictation、Cowork を公式 GUI 経路で利用できない
• Claude Code CLI は Linux でネイティブ実行できるが、ターミナルツールであるため Claude Code プラグインを Claude Desktop extensions として開発・テストする代替手段にはならず、現状ではプラグインのテストに macOS または Windows への切り替えが必要
• Claude Code はすでに signed apt、dnf、apk リポジトリと linux-x64、linux-arm64、musl バリアントのバイナリを提供しており、提案されている解決策は同じ配布パイプラインで Anthropic が運営する apt リポジトリから signed .deb を提供すること
• Cowork に関する根拠として Simon Willison、Pluto Security、pvieito のリバースエンジニアリング結果が引用されており、macOS では Apple Virtualization Framework ベースの Ubuntu 22.04 VM 内で Claude Code バイナリが実行されるという説明と、Anthropic ドキュメントにおける macOS/Windows ハイパーバイザー分離の確認があわせて示されている
• johnzfitch/claude-cowork-linux は、macOS native modules をスタブ化し、VM なしで Linux x86_64 上で Cowork モードを実行するコミュニティ移植版として提示されている
• Linux ユーザーは現在、Windows Electron ビルドのサードパーティ再パッケージに依存しており、aaddrick/claude-desktop-debian は signed apt/dnf リポジトリ、.deb、.rpm、AppImage、AUR、Nix ビルド、--doctor、CI テスト、Claude Desktop 1.11187.1 を追跡したリリースを提供しているが、vendor-signed および vendor-audited ではない
• Claude Desktop が OAuth tokens、API keys、extension configurations を扱う開発者ワークステーション向けの認証情報処理アプリケーションであることを踏まえると、公式 Linux ビルドの不在は信頼性とセキュリティへの懸念につながる
• 代替策として Claude Code CLI、claude.ai Web クライアント、コミュニティ再パッケージ、Wine 実行、macOS/Windows への切り替えが整理されているが、それぞれ desktop extensions、computer use、Cowork、統合の安定性、一次的なセキュリティアップデート、反復的な開発摩擦の面で限界があるとされる
• 初のビルドがロードマップにない場合は、インストール文書に Linux 未計画の状態とおおよその時期、推奨コミュニティプロジェクトの明示、1 回限りのセキュリティレビュー要約、Linux ユーザー向けの credential handling および MCP server configuration に関するセキュリティ指針を公開する代替案も要望

[GN⁺]

Hacker Newsの意見

• 非公式ビルドは https://github.com/aaddrick/claude-desktop-debian で管理されている
  名前には Debian と入っているが、対象範囲はいまやあらゆるバックエンドやコンポジタなどに広がっており、企業が Linux 向けの Electron アプリをなかなか出さない主因は ディストリビューションの断片化 だと思う
  単に Web ページをアプリのようにレンダリングする段階を超えると、すぐに複雑になり、テスト用 VM 一式をそろえても結局ずっと必要になる

  • 以前いた会社で、望んでいる顧客数は少なかったにもかかわらず Linux デスクトップクライアントを出そうとかなり頑張ってみたが、本当にあっという間に 互換性地獄 になるのを確認した
    最近の Ubuntu をいくつか対象にすれば大丈夫だろうと思っても、聞いたこともないディストリビューションでアプリの一部がまともに動かないという苦情が殺到する
    エンジニアが半日かけて VM にインストールしてデバッグしても、原因は上流プロジェクトのどこかにあり、正当化しにくいほど少ない顧客数のために Linux の issue チケットは増え続ける
    しかもその顧客たちは怒っていて声も大きい。13 年物の ThinkPad で見慣れないディストリビューションを動かしていることは伏せて、Twitter、Hacker News、Reddit に会社のソフトウェアはゴミだと投稿する
    オープンソースの Electron アプリでさえ、人気ディストリビューションのいくつかではコマンドラインの回避設定なしに動かず、それでも不安定なことが多い。オープンソースならまだしも、企業が配布すると望んでもいない怒れる顧客を抱え込むことになりかねない
  • 企業が Linux 向け Electron アプリを出していないというのは少し変だ。むしろ企業は Electron アプリしか出していないように見える
    デスクトップ Linux が自由・オープンソース圏外から何かを受け取るとしたら、たいていは Electron で、Spotify, Discord, Slack, VSCode のような例がずっと続いている
    過去 20 年で、営利企業が Linux 向けの GTK や Qt アプリをまともに提供した例はほとんど思い浮かばない
    非公式ビルドの取り組みは素晴らしいが、推定で兆単位の企業価値があり、学習データに Electron アプリが何千も入っていそうな製品なら、自分でコストを払うべきだ
  • Flatpak ならこうした問題のかなりの部分を解決できるのではないか？ アプリを 1 つのウィンドウマネージャー / デスクトップ環境向けに開発し、それを Flatpak の要件にすればよいように思える
  • Codex Desktop にも似たようなプロジェクトがある: https://github.com/ilysenko/codex-desktop-linux
    Linux に codex をインストールする手順を踏んでみると、OpenAI がなぜ公式ポートを出さないのか本当に理解できない
    アプリのすべてをテストしたわけではないが、意図どおりに動作し、computer use も問題なく動いていた

• Anthropic にはソフトウェア移植をうまくやる 自動化ツール みたいなものがあってほしかった

  • ソフトウェアを無限に作れるとしても、何に取り組むかについては依然としてかなり意図的である必要がある
    コーディングが今や「無料」だとしても、テスト、サポート、計画 のようなコストは残る
  • ボトルネックはそこではないように聞こえる
  • そこには allegedly が抜けている
  • 最先端の AI 企業が世界最高の AI を使って Linux 向けソフトウェアを開発し、まともなサポートまで提供することに決めてくれたらいいのにと思う
  • 単純なターミナルアプリに RAM 1GB が必要な既存の雑な代物で、さらに雑な Linux アプリを作るつもりなのかと思ってしまう
    総報酬が 50 万ドルを超える開発者の中に、しょぼくない単純なアプリを実際に使える形で書ける人がいてほしい

• 多くの人がこれを難しい問題だと言うが、Discord がこんな内容を載せていたのは興味深い
  「Linux ユーザーなら、アップデートがあるので自分でインストールしろと知らせるあの愛らしいモーダルにうんざりしていませんか？ それなら朗報です。Rust ベースの updater を Linux に移植したことで、Windows と同じように Linux でも自動更新できるようになりました。さらに、インストール用の .rpm と .pkg.tar.zst パッケージ形式もサポートします。」
  Discord は画面キャプチャ、音声キャプチャ、音声ルーティングを扱わなければならず、3 種類のパッケージリポジトリ もサポートする必要があるので、より厄介なクライアントに近い
  基盤側の問題を直してくれるなら、ビルド / ランタイム依存関係をバージョンごとに更新しなければならない点を受け入れればよい
  1 つのバイナリを配布して動かすということは、そのバイナリが依存するすべてのライブラリを一緒に載せる必要があるという意味で、Windows は winsxs でこれを処理するが、Linux は自分でやれと要求する

• デスクトップアプリで、CLI ではできないどの部分が惜しいのか気になる。自分も主に Linux を使っていて、ずっと普通に CLI を使ってきた

  • Anthropic のサブスクリプションでは、CLI はもはや日々の ルーチン を提供していないようだ
    また、会話間のメモリ検索は Claude Code とは別の会話データセット、つまり Claude Web / Claude.AI の会話を使っており、Claude Code が会話間検索をするのかもはっきりしない
    デスクトップインターフェースは Markdown をリッチテキストとして表示し、特にインタラクティブなアーティファクトを CLI よりずっとよく見せてくれる
    それでも実際には、ほぼすべての作業で CLI を使っている。Claude Desktop の日次ルーチンは合計 15 個の cron ジョブに制限され、追加使用量クレジットを消費するので、自前で最小限のハーネスを作って他プロバイダーのモデルへルーチンを移すつもりだ
  • Linux ではない同僚たちと同じ体験を使えれば、学んだことやプロセスを共有しやすい
    ローカルで動くスケジュールタスクも必要で、https://support.claude.com/en/articles/13854387-schedule-rec... の機能は Claude Code のルーチンと重要な違いがある
    同じフォルダ内で複数のプロジェクト / 分離されたメモリを扱う機能と、より良い UI も必要だ
  • デスクトップアプリは Code 機能を通じて、開いたままの リモートセッション を操作できるようにしてくれる
  • Claude が急に見せたがる インライン画像 を見たい。CLI だと画像は見られないとまた言い出すまで延々そうだから
    それ以外は CLI で満足している
  • CLI はコーディング作業には良いが、コーディングと無関係なほかのことにはデスクトップアプリがかなり便利なことがある

• Visual Studio 系アプリでバイブコーディングするために Electron アプリは欲しいが、自分で作りもせず他人のリポジトリをクローンしてビルドもしない Linux ユーザー市場がどれほどあるのかはわからない

  • よくはわからないが、Linux マシンで Claude Desktop を使えるなら、Anthropic の開発者報酬の半分しかもらえなくてもその役割を喜んで引き受けると思う
    Windows 向け Electron アプリを Linux で動かす サードパーティーのハックは、いつも使い心地が悪く感じられて嫌いだ
  • Claude アプリ自体は欲しくないので直接の利害関係はないが、最近の平均的な Linux ユーザーは、監視的なテレメトリや広告のようなものを望まないごく普通の人にますます近づいている

• いまだに多くの開発者が Linux の利用を見下しているのは驚きだ
  すでに Docker を使い、K8S にデプロイしているだろう。それも Linux の上で

  • OS 自体はあまり重要ではない。良いキーボードとトラックパッド、長いバッテリー駆動時間、鮮明な画面を備えた強力なノートPCが欲しい
    できればとても静かで、すっきりしたデザインならなお良い。それが MacBook の価値提案だ
  • それはまったく同じ話ではない
  • デスクトップとサーバーでは、サポートすべき対象範囲が完全に異なる

• もう一気にバイブで自分で作ればいい
  くだらなくはあるが、ここでみんなが話しているのが辛口の自動補完と自業自得の雇用破壊ばかりのときは、たまには自分で楽しみを作るしかない

  • 自業自得の雇用破壊という見方を、このひどいサイトで自分以外にもしている人がいてうれしい

• 個人的には、Claude Code に文字を緑色にして、The Matrix のように文字が画面の上から一文字ずつ降ってくるモードがなぜないのか理解できない

  • それはものすごく気になる。最近ちゃんと仕事をするには、緑のサングラスをかけて、言語を日本語にして、モニターを横向きにしなければならない

• 要望をどう表現するかには気をつけたほうがいい
  Claude をソフトウェア開発に使うのが目的なら、作業用に用意した Linux KVM VM サンドボックスの中で claude CLI 実行ファイルが必要なことをすべてやってくれて、デスクトップクライアントはなくても満足だ。よりクリーンで信頼できるほど良い
  質問を投げる一般的な対話用途はホストデスクトップの Web ブラウザーのサンドボックス内で行い、このやり方がしっかりサポートされてほしい
  AI 企業のマーケティングやプロダクト担当者は、当然ながら人々を専用のデスクトップクライアントへ押し込みたがるだろうが、それはまだ抑制できる乱用の一角だ
  ホストデスクトップと、そのアクセス先まで含めてエージェント型自動化で扱うのは遠慮したい。現在の技術水準はまだそこまで準備できていない

  • 問題は、VNC が RDP と比べてあまりにも出来が悪いことだ
    その VM 内の GUI クライアントへのアクセスがひどいので、そうでなければ GUI クライアントをここまで簡単には拒まなかっただろう

• 何百人ものユーザーが CLI エージェントを使っているのに、デスクトップ版を実際に自力で作れないという皮肉が面白い
  LLM は人々をそこまで無力にしているのだろうか？

  • Anthropic が Openclaw を止めようとして claude -p をめぐって騒ぎになっていた直後だったので、その余波に巻き込まれたくなくて避けていた
    両者のやり取りを追うのは大変だったが、もう終わったようにも見える
  • 1 日に何度も更新が出る製品を、1 人で追い続けるのは難しい
  • 要望に 公式 という単語が入っている点を見るべきだ。非公式版はすでにある