Orca を入れたのに orca が見つからない：まず orca-ide として入ったか確認（2026-10 確認）

入れ失敗ではなく、名前の問題です。公式の install ページはコマンド名だけの節を建てており、Linux では Orca CLI は orca-ide として入ります。GNOME 標準のスクリーンリーダーが /usr/bin/orca をすでに押さえていて、Orca はそれを遮蔽しないからで、.deb と .rpm のパッケージ名も同じ理由です。orca が反応しないのは、多くの場合このコマンドが最初から別の名前だったからです。

tap を伴わない orca という cask は、このプロジェクトのリリース経路ではないから。Homebrew の公開メタデータは 2026-09-23 の取得で disabled: true、disable_date 2026-09-01、disable_reason が fails_gatekeeper_check（同時に deprecated は今も false）。2026-10-20 に再確認しても disabled は true、deprecated は false のままで、disable_date と disable_reason も変わっていない。公式 install ページが示すのは tap 付きのそのコマンド（tap の後ろの cask パスは stablyai/orca/orca）、更新は cask 指定のそのコマンドで、その cask は stable チャネルに従うと書かれている。

公式の原文どおり、各リリースが AppImage、.deb、.rpm の三種を出す（x64 と arm64 の両方がある）：中のアプリは同じで、違うのは更新の届き方だけ、だからそこを基準に選ぶ —— つまり選び分けの基準は「更新が自分の手元にどう届くか」だけで、機能差ではない。Arch 向けの道 stably-orca-bin、またはソースからビルドする stably-orca-git を選ぶ。

公式の troubleshooting ページが示するのは登録の手順です。Settings → General → Orca CLI で CLI を登録します。macOS では ~/.local/bin に shim が置かれ、続けてそのディレクトリが shell の PATH に入っているかを確認します。言い換えれば、再インストールでは直りません。足りないのは PATH のあの一行です。

公式の troubleshooting ページが挙げる条件は次の通りです。リモートに Node があり、初回 relay インストール時に外に出られること。Linux のリモートには make、g++/clang++、python3 の C/C++ ツールチェーンを足すこと。入れ終えたら一度つなぎ直し、Orca にネイティブモジュールを入れ直させること。別のページ（headless Linux server）はサーバー側の前提も補います。デスクトップのないサーバーイメージには Electron の共有ライブラリが入っていないので、Xvfb とそのライブラリをまとめて入れる必要があります。

公式の headless ページは原因を二層に分けます。ペアリングに使う offer 自体はデバイス資格情報とエンドツーエンド暗号の鍵を含むので、対象クライアントにだけ渡し、プロキシのアクセスログにも残しません。つながらないのはたいていネットワーク側です。boundEndpoint はプロセスが待ち受けるアドレス、advertisedEndpoint はクライアントがダイヤルするアドレスで、公式の記述によれば DNS、ファイアウォール、Docker のポート公開、Tailscale の方針、リバースプロキシのいずれかが advertised を bound に中継できなければ、見かけ上問題ない offer でもつながりません。