Hermes Desktop

Hermes デスクトップアプリは、CLI やゲートウェイで動くのと同じエージェントをそのまま包んだネイティブアプリです。設定も API キーもセッションもスキルもメモリも共通です。別製品でも簡易版のクローンでもなく、同じ Hermes Agent のコアと設定を使い、それを現代的に設計された UI から動かします。ターミナルで hermes を使ったことがあるなら、そこで整えたものはすでにここにありますし、ここでやったことはそちらにも現れます。

動作環境は macOS（Apple Silicon）・Windows・Linux です。対応状況の全体は Platform Support を参照してください。

導入

Hermes Desktop の製品ページからアプリをダウンロードするか、Hermes Desktop のインストール手順に従ってください。

すでに Hermes を入れてあるなら、次を実行するだけです。

hermes desktop

いま使っている設定・キー・セッション・スキルがそのまま使われます。

アプリの中身

デスクトップアプリは、チャットを主役に据えたウィンドウと、左側のナビゲーション用サイドバーで構成されています。複数のエージェントとの会話を同時に進め、メッセージングのプロバイダーを設定し、アーティファクトを作り、プロジェクトのフォルダ構成を眺めながら、いくつものプロジェクトを並行して扱えるように作られています。

サイドバーの選択状態は、フォーカスされているチャットペインに追従します。セッションタブを開いたりフォーカスしたりすると、ワークスペースがそのページのルートを保持したままでも、Kanban のような外部から追加されたページを含めて、ページ側のハイライトは外れます。

チャット

アプリの中心です。次のものが使えます。

• ストリーミング応答 — エージェントが作業する様子を、ライブのツール実行状況と構造化されたツール呼び出しの要約として流します。ツールが画像を扱ったとき（たとえばバックエンドのファイルシステム上のファイルに対する vision_analyze）は、その実行行を開くと画像が見え、クリックすれば原寸で開きます。リモート接続の場合、画像はアプリが動いている端末ではなくゲートウェイから取得されます。
• Markdown の改行は Markdown の意味論どおりに扱われます。行末のスペース2つは強制改行になり、ふつうの改行はソフト改行のままです。メディアとプレビューの抽出は、取り除いた添付範囲の外側にあるテキストを、先頭行のコードのインデントや閉じていないコードフェンスの空白も含めて保ちます。コードの表示とコピーは、Markdown パーサーが返した先頭の空行・行末のスペース・末尾の空行を保ちます。
• 他のどの Hermes の画面とも同じ会話履歴 — ここで始めたセッションは CLI/TUI で再開できますし、その逆もできます。
• ファイルのドラッグ&ドロップ — チャット領域のどこに落としても、次のメッセージに添付されます。
• 背後のドラフトは独立して動く — 表示されていないチャットタブは、見えているコンポーザーのカーソル位置や選択範囲を動かさずに自分のドラフトを更新できます。
• 未送信のドラフトはセッションが消えても残る — すでに存在しないセッション（別の場所で削除された、あるいはプロファイル名の変更やバックエンドの初期化で古くなったタブ）に打ち込んでいたドラフトは、アプリが代わりに開く新しいチャットへ運ばれ、入力欄の上に 未送信のメッセージを復元しました という帯がインラインで出ます。元に戻すを押せばテキストは元の場所へ戻ります。勝手に送信されたり、画面が移動したり、フォーカスが奪われたりはせず、この帯は失われたドラフト1件につき一度だけ出ます。
• ディレクティブチップの操作 — 操作できる参照（URL など）にマウスを乗せると、その操作ピルが現れます。少し猶予があるので、チップからピルへマウスを移す間に消えてしまうことはありません。ピルの上で動いている間は出たままで、離れたあとは関係のないマウス移動で消えるのが遅れることもありません。その操作をクリックしても、ドラフトの選択範囲はそのまま残ります。
• 右側のプレビューレール — Web ページ・ファイル・ツールの出力を、チャットを続けたまま横に並べて表示できます。
• 状態を持つペインは Close ではなく Hide — Browser（または HTML プレビュー）や Terminal のペインを抱えているゾーンには、Minimize ではなく Hide が出ます。Hide するとゾーンは復元用のレールまで畳まれますが、ペインの中身はマウントされたまま残ります。生きているページなら未保存のフォーム入力・タイマー・スクロール位置・エージェントの drive_preview の操作対象が保たれ、ターミナルなら動いているシェルとスクロールバックが保たれます。Restore を押せば、読み込み直すことなく同じ内容が戻ります。隠れている中身は不活性で、キーボードショートカットを取ったりコンポーザーからフォーカスを奪ったりしません。ページやシェルを実際に手放すのはタブの × である Close のほうです。
• アプリ内ブラウザのコメントモード — プレビューブラウザのバーで Annotate を押し、表示中のページの要素をクリック（または範囲をドラッグ）してメモを書きます。保存したコメントは番号付きのピンとしてページに残ります。ピンを保存してもターンは送られません。書き終えたら Add N comments で、ピンごとに切り取ったスクリーンショットと各コメントを指す短いプロンプトがコンポーザーに付きます。送信するのは自分の手です。要素へのコメントには CSS セレクタ・そのマークアップ・レイアウトに効く算出済みスタイルが付くので、エージェントは画像から推し量るのではなく、元のソースの中からその要素を見つけられます。パスワードや隠しフィールドの値、キーやトークンらしき属性は、マークアップがページの外へ出る前に伏せられます。数が多いときは、ページのどの部分にあるかでまとめられて届くので、20 個あまりのコメントが 20 件の作業ではなく数個の作業になります。まとまりは別々の DOM のサブツリーなので触るファイルもたいてい分かれ、だからこそ複数のワーカーへ同時に渡しても安全です。ピンの番号は1つ消しても動かず、チャットを切り替えると積み上がったものは消えます。
• コンポーザーの履歴とキューの編集 — 空のコンポーザーで上下の矢印キーを押すと、前に書いたプロンプトを呼び出して使い回せます。順番待ちにしたメッセージも、送られる前なら編集できます。ターンが順番待ちの状態で Stop（または Esc）を押すとキューが止まってコンポーザーの上に開き、そこから再開したり、個々の項目を送信・編集・削除したりできます。キューそのものはゲートウェイの側にあるので、アプリやゲートウェイを再起動しても残り、同じチャットにつないでいるどのウィンドウにも同じ一覧が見えます。ターンの途中でゲートウェイが再起動した場合、そのターンは最後まで進めることも安全にやり直すこともできません。キューにはそのターンが Turn lost during restart と表示され、ボタンは Discard の1つだけになり、後ろに並んだターンはそれを破棄するまで待ちます。書いた文章はトランスクリプトに残るので、送り直せます。（ゲートウェイの CLI でも /discard <admission_id> で同じ操作ができます。）
• コンポーザーの上に出るタスクの進み具合 — Tasks の見出しを開くと各段階を確認できます。長い一覧でも入力欄の上に収まる高さに抑えられ、開いた一覧の中をスクロールすれば、会話を動かさずに最後のタスクまでたどれます。
• 会話のタイムラインレール — 長いチャットでは、トランスクリプトの端にプロンプト1件につき1つの印が並んだ細いレールが出ます。マウスを乗せるとプロンプトの一覧が開き、選べばその地点へ一気に移動します。移動したあとはトランスクリプト上部の Show earlier で、そのプロンプトからセッションの最初まで遡り続けられます。（チャットにいくつかターンが溜まると出てきます。）
• 読んでいた位置を覚える — セッションに戻ったとき、いつも最新のメッセージへ飛ぶのではなく、保存してあった「下端からの距離」が復元されます。下端に置いたままにしたセッションは、そのまま新しい出力を追い続けます。Scroll to bottom で最新の位置へ戻れます。位置はこの Desktop のインストール先のローカル保存領域に置かれ、バックエンド越しに同期されることはありません。
• ページ内検索 — Cmd/Ctrl+F で検索バーが開き、描画済みのチャットのトランスクリプトを検索します。Enter / Shift+Enter（バーが開いている間は Cmd/Ctrl+G / Cmd/Ctrl+Shift+G でも）で一致箇所を送り、Esc で閉じます。

非同期の cron や委任の完了は、畳まれたタイムラインの開閉項目として現れます。完了のラベルを開くと、ジョブの出力を含む結果の本文を Markdown として読めます。長い報告は開いた領域の中でスクロールします。タスクへの指示や配送用のエンベロープは、報告の中身としては表示されません。

ステータスバー

チャットの下端に走るバーは、セッションの状態をその場で映し、設定を開かずに素早く操作できる項目を出します。

• セッション単位の YOLO 切り替え — このセッションだけ YOLO を入れたり切ったりできます（TUI と同じ挙動です）。YOLO は危険なコマンドの承認プロンプトを飛ばすので、何を外しているかを分かったうえで使ってください。Security → YOLO Mode を参照してください。
• コンテキスト使用量メーター — そのセッションのコンテキストウィンドウが何 % 埋まっているかをその場で表示します。クリックすると Context Usage のポップオーバーが開き、カテゴリ別（システムプロンプト、ツール定義、スキル、メモリ、ルール、MCP、サブエージェント定義、そして会話そのもの）のトークン内訳が見えるので、圧縮が始まる前に何がウィンドウを食っているかを正確につかめます。
• キャッシュヒット率と1秒あたりのトークン数 — 既定では非表示で、右クリックメニューから出します。キャッシュヒット率は、このセッションの入力トークンのうちプロバイダーのプロンプトキャッシュから返された割合です（キャッシュされたトークンは安いので、高いほど安く済みます。セッションが温まるにつれて安くなっていく様子が見えます）。1秒あたりのトークン数は、直近 10 回のモデル呼び出しで平均した出力の速度です。どちらもターンの途中で更新されます。
• 表示項目を選べる — ステータスバーを右クリック（Show in status bar）すると、何を出すかを選べます。コンテキストメーター、キャッシュヒット率、1秒あたりのトークン数、ワークスペース、モデル、承認、ターン／セッションのタイマー、ターミナル、Command Center、バックエンドのバージョンなど。バー自体を隠すこともできます（Cmd/Ctrl+Shift+S で切り替わります）。ワークスペース項目のメニューに Open containing folder が出るのは、フォーカス中のセッションがこの端末で動いているときだけです。リモートのゲートウェイ上のセッションはフォルダも向こうの端末にあるので、代わりに Reveal in filetree を使ってください。OS のファイルマネージャーがパスを見つけられないときは、何も起きないのではなく、アプリがその旨を伝えます。

同梱のローカルバックエンドではなく、別の端末で動く Hermes に向けて話していますか？ 下のリモートバックエンドへの接続を参照してください。リモートでホストされたダッシュボードへの接続がどう働くか（認証のゲート、/api/ws のチャットソケット、WebSocket のクローズコードの切り分け）の全体像は、Web Dashboard → Connecting Hermes Desktop to a remote backend にあります。

フォント

Settings → Appearance には独立した2つのフォント設定があり、どちらもプロファイルごとに config.yaml へ保存されます。

• Chat Font（desktop.font_family） — チャットとアプリ UI 全体に効きます。OpenDyslexic や Atkinson Hyperlegible のような読みやすさ重視の書体は、システムに入っていればすぐ使えます。選んだ書体の後ろには現在のテーマのフォントスタックが残るので、足りない字形もきちんと描かれます。空欄ならテーマのフォントになります。
• Terminal Font（terminal.font_family） — 埋め込みのターミナルペインに効きます。ここでは Nerd Fonts がシェルのアイコンを描きます。空欄なら同梱の JetBrains Mono になります。

リポジトリの検出

Hermes Desktop は、ホームディレクトリを決められた深さまで走査して、Projects サイドバー用にローカルの Git リポジトリを見つけます。これは Settings → Workspace か config.yaml で、プロファイルごとに変えられます。

desktop:
  repo_scan_enabled: true
  repo_scan_roots: []
  repo_scan_exclude_paths: []

• repo_scan_enabled: false にすると、ファイルシステムの走査を完全に止めます。そのプロファイルのディスク検出キャッシュの行は消えますが、明示的に登録したプロジェクトと、意図して始めた Hermes セッションから推定されたリポジトリは残ります。
• repo_scan_roots にフォルダの一覧を設定すると、走査する範囲をそこに絞れます。空の一覧なら既定のホームディレクトリ走査のままです。
• repo_scan_exclude_paths には、配下をまるごと飛ばしたいフォルダを設定します。

これらの値を変えると、そのプロファイルのディスク検出キャッシュだけが無効になり、方針に沿った再取得が始まります。Hide from sidebar は、項目ごとに手で整理するための別の操作のままです。

Group by → Projects にすると、各プロジェクトの行に直近3件のセッションが並びます。それより多いプロジェクトの末尾には Show all N sessions の行が出て、その場で残りが開きます。サイドバーのメニューにある Show all sessions を入れると、すべてのプロジェクトで件数の上限が一度に外れます。

モデルを選ぶ

モデルの選択はコンポーザー、マイクのすぐ左にあります。クリックすればモデルを切り替えられ、モデルの行にマウスを乗せればその選択肢（thinking、effort、fast）が出ます。その隣の reasoning ピルは、いま使っているモデルの effort の段階（Med、High など）を示し、押すと同じ選択肢が直接開くので、モデルの行を探さなくても effort を変えられます。カタログ上で推論の制御を持たないモデルでは、このピルは出ません。経路が Hermes 内部の段階を丸めるとき（ultra はその経路で最も強い段階、たとえば max として送られます）、ピルは両端を並べて Ultra→Max と表示し、ツールチップには CLI と同じ言い回しの Ultra (sends Max on this route) が出ます。見えている段階と実際に送られる段階が食い違わないようにするためです。ゲートウェイが切り替えを危険と判断したとき（キャッシュの大きいコンテキスト、高価なモデル、データ学習の対象となる層）は、アプリがまずダイアログで確認します。Switch anyway で適用され、Keep current model（または Esc）なら何も変わりません。

マイクはディクテーションです。マウスを乗せると、その上に他の音声の切り替えが開きます。Read replies aloud と、ウェイクワードの耳のアイコンです。入っている切り替えは塗りつぶされた円で示されます。本格的な音声会話を始めるボタンは、右側の主ボタンのままです。HUD や幅の狭いタイルでは、同じ操作がマイクの後ろの1つのメニューにまとまります。ディクテーションが音声認識のプロバイダーと直接やり取りするとき（クライアント直結の音声）も、ゲートウェイ自身の文字起こしクライアントと同じ stt.openai.timeout の制限（既定 60 秒）に従うので、遅いエンドポイントに当たってもマイクが文字起こし中のまま固まらず、「Transcription timed out」で失敗します。

• コンポーザーの選択は UI の状態であって、既定には触れません。 選択は端末ごとにローカルで覚えられ、既定へ戻らずに新しいチャットや再起動をまたいでついてきます。一度選んでおけば、次の Cmd/Ctrl+N はそのモデルで開きます。開いているチャットでモデルを切り替えた場合、その変更はいま開いているチャットの範囲にとどまります。どちらの場合も選択はセッションの作成・切り替えのときに一緒に運ばれ、プロファイルの既定として書き込まれることはありません。例外は1つだけで、model.default / model.provider がまだ設定されていない新品のプロファイルでは、最初の選択が保存されます。再起動時に無関係な API キーの環境変数へ落ちてしまわないよう、実体のある既定を持たせるためです。保存の挙動は /model と同じ規則（model.persist_switch_by_default）に従います。既定を意識して変えるときは Settings → Model を使ってください。（プロファイルを切り替えると、そのプロファイル自身の既定から引き直されます。）
• 既定は Settings → Model で決めます。 この「メイン」のモデルがプロファイルごとの全体の既定で、新しいチャット・cron・サブエージェント・補助タスクはここから始まります。ここだけがその値を書き込みます。プロファイルごとに独自の既定を持ちます。
• モデルごとの effort / fast のプリセット。 デスクトップアプリでは、モデルそれぞれが自分の推論 effort と fast モードの選択を覚えていて、そのモデルを選ぶたびにセッションへ適用し直されます。これはデスクトップ側の便利機能で、cron やサブエージェントには影響しません。
• お気に入りのモデル。 モデルの行の左にある星をクリックすると（行を Shift+クリックしても同じです。サイドバーでチャットをピン留めするのと同じ操作で、検索欄からは Shift+Enter）、そのモデルが選択画面の一番上の Favorites 欄に上がります。星を付けてもモデルは選ばれず、メニューも閉じないので、同じ操作でそのまま取り消せます。この欄は、何かに星を付けたときだけ現れます。お気に入りは1つの保存済みの設定なので、コンポーザーにも、セッションのタイルにも、ほかにモデルを選ぶ場所にもすべて出ます。端末ごとに保存され、星を付けた順に並び、Edit models の絞り込みとは関係なく表示されます（星は「これはいつも見せてほしい」という明示の指定だからです）。接続していないプロバイダーのお気に入りも消えずに残り、接続し直すとまた現れます。検索には影響しません。検索すると、一致したものがすべてそれぞれのプロバイダーの位置に並びます。
• チャットの途中で切り替えるとプロンプトキャッシュが白紙に戻ります。 開いているチャットでモデルを変えると、次のメッセージは会話全体を入力の正規料金で読み直すことになります（プロバイダーのプロンプトキャッシュはモデルごとに分かれているためです）。たまになら構いませんが、長いチャットでは行ったり来たりするより、新しいモデルで新しいチャットを始めるほうが安く済むことが多いです。

ファイルブラウザ

アプリを離れずに作業ディレクトリを見て回り、中身をプレビューできます。エージェントがファイルを読み、書き、直していく様子を追いかけるのに向いています。最初に開くプロジェクトのディレクトリは hermes desktop --cwd <path>（または環境変数 HERMES_DESKTOP_CWD）で指定します。

アーティファクト

コンポーザーの上に出るプレビューのリンクは、そのセッションからの提案であって、タスク完了のチェックリストではありません。1つ閉じておけば、画面を移動したり再読み込みしたりしても、過去のツール実行の行がそれを呼び戻すことはありません。ツールが新たに成功すれば、同じファイルをまた提案できます。読み取りだけのファイル確認や、失敗した書き込みからは提案が生まれません。同じ名前のファイルには、見分けがつくだけのディレクトリの情報が添えられます。提案を閉じても、そのファイルやトランスクリプトが消えるわけではありません。/goal を変えても、その会話のアーティファクトは消えません。

リモートのゲートウェイにつないでいるとき、ファイルのアーティファクトを開くと、そのゲートウェイ経由で、アーティファクトの出どころのプロファイルとセッションを使ってダウンロードされます。相対パスはセッションに保存された作業ディレクトリを基準に解決され、ホーム基準のパスはゲートウェイ側のホームを指します。Desktop が動いている端末のホームではありません。Windows 形式の相対パスもスラッシュ区切りのパスと並んで認識され、file URI はドライブやネットワーク共有の情報を保ったままゲートウェイへ渡されて解釈されます。セッションや作業ディレクトリが見つからないときは、別のローカルファイルを勝手に選ぶのではなくエラーになります。

画像付きのメッセージが受け付けられる前にデスクトップが閉じた場合は、元のチャットを開き直してください。コンポーザーの上にある Restore image draft のボタンで、保存されていた文章と画像の添付がまとめて戻ります。Send を押すと、元の送信をやり直します。自動で送ることはなく、もっと新しい下書きを上書きすることもありません。

Artifacts のビューは、セッションが生み出したもの（画像・ファイル・リンク）を、検索して見て回れる1つのギャラリーに集めます。サイドバー、コマンドパレット（Artifacts — Browse generated outputs）、あるいは自分で割り当てた nav.artifacts のショートカットから開けます。直近のセッションの出力は自動で索引され、どのアーティファクトにもそれを作ったセッションが示されてそのチャットへ戻れます。画像とファイルはプレビューで開き、ダウンロード／ブラウザで開く／コピーの操作ができます。

ウィンドウ・タブ・ペイン

このアプリは、いくつものことを同時に進めるために作られています。

• タブ — Cmd/Ctrl+T で新しいセッションのタブが開きます。Ctrl+Tab / Ctrl+Shift+Tab でセッションを順に切り替え、Ctrl+1…9 で位置を指定して最近のセッションへ飛べます。Cmd/Ctrl+W でフォーカス中のタブを閉じます（ただし対話型のターミナルの上では、シェル本来の意味である単語の削除として働きます）。Cmd/Ctrl+Shift+T で最後に閉じたタブを開き直せます。
• 複数のウィンドウ — Cmd/Ctrl+Shift+N で新しいウィンドウが開きます。どのセッションも、コンテキストメニューの New window かコマンドパレットから切り出せます。切り出したウィンドウは、全体のサイドバーなしでそのチャットだけを描くので、長く走るセッションを別のモニターに置いておくのに便利です。エージェントの出力は、そのセッションを映しているすべてのウィンドウへ同時に流れます。
• ペイン — Cmd/Ctrl+B で左サイドバー、Cmd/Ctrl+J で右サイドバーを出し入れし、Cmd/Ctrl+\\ で両サイドバーの左右を入れ替えます。

表示モード

レイアウトエディター（タイトルバーのボタンか Cmd/Ctrl+Shift+\\）を開くと、まず Interface mode の選択が出ます。同じ選択は Settings → Appearance → Window & layout にもあり、コマンドパレットでは *Simple mode* として出てきます。変わるのは画面に何を出すかで、Hermes にできることは変わりません。

• Advanced（既定）は、自分で整えたとおりのアプリです。Simple を明示的に選んでいない人は Advanced のままです。
• Simple はチャット中心の表示です。ステータスバー、プロファイルレール、ターミナル、ファイルブラウザとレビューのペイン、技術的なツール呼び出しの表示、インラインのコード差分、Artifacts / Scheduled jobs の行は、邪魔にならないよう控えに回ります（Capabilities と Messaging は残ります。Hermes を設定するための入口だからです）。思考は折りたたんだ状態で始まり、セッションの行にはタイトル、プレビュー、最後に動いた時刻が出ます。タイトルバーには Settings とレイアウトエディターが残ります。Simple のレイアウト選択では *Sidebar left* か *Sidebar right* を選べます。テンプレートと保存したレイアウトは Advanced 側のものです。

レイアウトは、物の置き場所だけでなく、画面に何が出ているかも決めます。適用すると、そのレイアウトが置くペインはすべて開き、*控え*に回すペインは閉じます。そのため Ctrl+**、**Cmd/Ctrl+J**、**Cmd/Ctrl+G** の状態は、いつも見えているものと一致します。*Basic* はセッションとチャットだけの構成で、ターミナルはチャットの下に折りたたんだレールとして控え、ファイルブラウザとレビューは右の列に控えています。**Ctrl+ でチャットの下にターミナルが開き、Cmd/Ctrl+J で右にツリーが開きます。*Focus* はファイルとレビューをチャットの裏のタブとして持ち、ターミナルのレールは同じです。*Default*、*Terminal deck*、*Quad* は、置くものをすべて開きます。自分で保存したレイアウトは、どのペインを閉じていたかも覚えています。

モードごとに、それぞれの配置を覚えています。ペインの位置、サイズ、アクティブなタブ、隠したタブ、閉じた通知、折りたたんだ側、浮いているカードの位置です。モードに戻ると、プリセットを当て直すのではなく、その配置が戻ります。Simple はサイドバーが左の状態で始まり、右へ動かしても Advanced 側は変わりません。会話、下書き、プレビュー、実行中の作業は両方のモードで共通です。

アップデートしても、既存のレイアウトは残ります。Advanced は元の保存キーをそのまま使います。すでに Simple を明示的に選んでいた場合は、そのときのレイアウトが Simple 専用の保存先へコピーされ、元のものは消えません。この分離より前に上書きされてしまった古い配置は、復元できません。

Simple は表示の設定を上書きせず、上に重ねるだけです。Simple でもすべてのキー操作が効きます。Ctrl+`、Cmd/Ctrl+J、Cmd/Ctrl+G で、いまのセッションのターミナル、ファイルブラウザ、レビューが開き、次に起動したときはまた静かな画面に戻ります。プロファイルが2つ以上あるときは、切り替える手段がそれしかないので、プロファイルレールは残ります。初回のオンボーディングでは、選んだレイアウトからモードが決まります。*Basic* なら Simple、*Elite* なら Advanced で始まり、飛ばした場合は Advanced のままです。

トレイへ最小化

Settings → Appearance → Window layout → Minimize to tray を入れると、最小化したウィンドウがタスクバーや Dock から消えたまま、セッションは動き続けます。既定では切ってあり、この端末にだけ効きます。

この設定を入れてトレイが使える状態なら、メインウィンドウを X や Alt+F4 で閉じても、Hermes は止まらずセッションも壊れずに、ウィンドウが隠れるだけになります。副次的なウィンドウはこれまでどおり閉じます。隠れたウィンドウを戻すには、システムトレイ（macOS ならメニューバー）の Show Hermes を使います。トレイメニューの Quit Hermes と Cmd+Q はこれまでどおり終了し、作業中の確認も通常どおり出ます。トレイが使えない場合、メインウィンドウを閉じる動きはふだんどおりです。

macOS では、ふつうの Hermes のウィンドウが1つも見えなくなったときにだけ Dock のアイコンが消えます。Linux では StatusNotifier のトレイホストが登録されている必要があり、それがないデスクトップ環境では最小化はふだんどおりに振る舞います。ホストが消えた場合、隠れていたウィンドウは戻ります。

ターミナル

右サイドバーの、ファイルブラウザの隣に本物のターミナルがあります。

• Ctrl+** を押すとターミナルが出ます（1つもなければ新しく開きます）。**Ctrl+Shift+ ならもう1つ増やせます。複数のターミナルはタブのレールに並び、Ctrl+Shift+↓/↑ で行き来し、Ctrl+Shift+W で今のものを閉じます。
• 隠れている間もシェルは生き続けます。 パネルを閉じたり隠したりしてもシェルは死にません。開いているターミナルはすべて、スクロールバックも実行中のプロセスも保ったままマウントされ続け、明示的に閉じるまで残ります。
• Add to chat — ターミナルの出力を選んで、次のメッセージの材料としてコンポーザーへ送れます。

動いているサブエージェント

委任したワーカーが動いている間、コンポーザーの上に Subagents の枠が出て、その数・タスク名・経過時間・直近の動きが並びます。表示するのは3人までで、見出しを開けば全員が並び、1人を選べば詳細と Steer / Stop の操作が出ます。この枠は分割ペインの中でも、それぞれのチャットに属します。Steer は、指示が節目に向けてキューに入ったことを知らせるだけで、子がすでに読んだという意味ではありません。Monitoring subagents を参照してください。

Git のレビューと worktree

Git リポジトリの中で動いているセッションには、組み込みのソース管理の画面があります。

• レビューペイン — Cmd/Ctrl+G で作業ツリーのレビューペインを出し入れします。ブランチと ahead/behind の状態、変更されたファイル（リスト表示かツリー表示）、そして Uncommitted・Branch・Last turn（エージェントが直近のターンで変えた分だけ）に絞った差分が見えます。ファイルをステージ／アンステージし、変更を取り消し、コミットメッセージを書き（Generate commit message もあります）、Commit か Commit & Push を押します。GitHub CLI（gh）を使った Create PR もありますし、Ask Hermes to open PR でまるごとエージェントに任せることもできます。ここからブランチを作って切り替えることもできます。Last turn の範囲には、このリポジトリで直近のターンが始まってから変わったものがすべて出ます（ターンの途中でエージェントが作ったコミットも含みます）。ここでまだ一度もターンが走っていなければ空です。Branch と Last turn の範囲は読み取り専用で、ステージ・取り消し・コミットが効くのはまだコミットしていない変更だけです。
• worktree — Cmd/Ctrl+Shift+B（またはサイドバーのプロジェクトの New worktree）で、新しいブランチの上に Git の worktree を作ります。自分のチェックアウトに触れずに、エージェントがリポジトリの並行コピーで作業できます。worktree はプロジェクトの下に独自のレーンとして並び、片づけるときは worktree のディレクトリごと消す（ブランチは残ります）か、レーンを隠すだけでディスクには残すかを選べます。コミットされていない変更があるときは強制するための選択肢も出ます。チャットはエージェントについていきます。worktree を作ってそこで作業するよう頼むと、ターンの終わりにチャットがそのレーンへ移り、サイドバーの表示範囲も一緒に切り替わります。その場にとどまるのは、自分で意図してチャットを切り替えた作業場所（フォルダーの選択、またはプロジェクトの切り替え）だけです。

メモリグラフ

Memory Graph（コマンドパレット → *Memory Graph*、またはステータスバーの項目）は、Hermes があなたのために学んできたものを対話的に見渡せる地図です。スキルとメモリが拡大縮小できるノードのグラフとして並び、時間軸が付いていて、All / Used / Learned で絞り込めます。共有の操作を使うと、地図の配置を短いコードとして書き出して誰かに貼って渡せます（配置だけで、メモリやスキルの文章は一切含まれません）。同じやり方でコードを読み込むこともできます。

Quick Entry

Quick Entry は、システムのどこからでも使えるグローバルなホットキーで呼び出せる、いつでも開ける小さなコンポーザーです。メインウィンドウへ切り替えなくても（そもそも開いていなくても）プロンプトを投げられます。Settings → Advanced → Quick Entry で有効にします。既定のショートカットは Ctrl/Cmd+Shift+Space で、自分のものに変えられます（修飾キーが最低1つ要ります）。その組み合わせを他のアプリがすでに握っている場合は、設定の行がそう教えてくれるので、別のものを選べます。

音声

Hermes に話しかけ、返事を聞けます。他の場所で使えるのと同じ音声モードです。macOS では、OS が一度だけマイクの許可を尋ねます。

HUD モード

⌘/Ctrl+Shift+H（またはタイトルバーのボタン）を押すと、チャットが装飾のない常に最前面の浮遊バーとして切り離され、いま作業している画面の上に載ります。アプリのウィンドウは脇へどき、HUD が会話とコンポーザーを引き継ぎます。どこに置くかが文脈になります。バーの位置が、どのアプリのどの画面について尋ねているかを Hermes に伝えるので、「これ」「ここ」「このページ」がその下にあるものを指すようになります。

• バーを動かす — macOS と Windows では、コンポーザーのどこかを少し長押ししてからドラッグします。Linux/X11 では Ctrl を押しながら主ボタンでドラッグすると、選択中のテキストの上からでもすぐつかめます。長押しも使えます。つかんだままデスクトップ切り替えのショートカットを押せば、HUD を別の仮想デスクトップへ連れていけます。ネイティブ Wayland では、コンポーザーのバーがコンポジターのドラッグハンドルそのものです（アプリが自分のウィンドウ位置を決められないため、これが動かす唯一の方法です）。
• 大きさを変える — バーの辺か角をドラッグします。反対側の辺は固定されたままです。ネイティブ Wayland では右と下の辺だけが使えます。コンポジターがアプリにトップレベルウィンドウの位置決めを許さないためです。
• レイアウトを戻す — バーにある破棄の操作で、既定の大きさと（X11 / macOS / Windows では）位置に戻ります。保存された大きさのせいで HUD が使いものにならなくなったときに使ってください。
• タップで呼び出す — Settings → Keyboard Shortcuts → HUD gesture の Tap to summon HUD を有効にして、macOS なら ⌘+Option、Windows/Linux X11 なら Ctrl+Alt をタップして離します。他のキーやマウス操作を挟まずに、0.5 秒以内に両方を離してください。Windows では左の Alt を使います。右の Alt は AltGr 配列のために予約されています。これは別のアプリから HUD を開いたりフォーカスしたりするもので、閉じる方向には働かず、音声を録ることもメッセージを送ることもありません。既定では切ってあり、この端末にだけ保存されます。macOS では入力監視の許可が要ります。このページに復旧用の操作が出るのは、許可などの問題に対処が必要なときだけです。Linux の Wayland はこのジェスチャーを扱えないので、そこではアプリ内の HUD ショートカットを使い続けてください。
• ポインタへ寄せる — ⌘/Ctrl+Shift+G（どのアプリからでも効くグローバルホットキー）で、HUD がカーソルのある場所へ飛びます。ネイティブ Wayland では何も起きません。配置はコンポジターが握っているためです。
• 抜ける — バーの終了ボタンを押すか、⌘/Ctrl+Shift+H をもう一度押すか、HUD にフォーカスがある状態で ⌘/Ctrl+W を押します。アプリのウィンドウがセッションとともに前面へ戻り、カーソルはコンポーザーに入ります。

Linux / Wayland

ローカルの Wayland セッション（XDG_SESSION_TYPE=wayland のとき、または WAYLAND_DISPLAY が設定されているとき）では、Hermes は --ozone-platform=wayland を付けて起動します。Electron が XWayland へ落ちないようにするためです。プラットフォームは、アプリケーションの JavaScript が読み込まれる前に、プロセスのコマンドラインに載っていなければなりません。明示的な --ozone-platform、desktop.ozone_platform_hint: x11、desktop.electron_flags の中の ozone プラットフォーム指定は、これまでどおりそちらが優先されます。ドラッグ・クリックの通過・リサイズは、ネイティブ Wayland の経路で動きます。

Hyprland（Omarchy を含む）では、HUD はマップされたあとにコンポジターの IPC を通してフロート化・ピン留めされます。そうしないと Hyprland が他のウィンドウと同じようにタイル配置してしまい、always-on-top は無視され、コンポジターのドラッグも効きません。追加のウィンドウルールは要りません。

一部のコンポジター（とくに COSMIC）は、ネイティブ Wayland のウィンドウに対して always-on-top を無視します。そこでピン留めを取り戻すには、アプリを XWayland の下で動かします。

desktop:
  ozone_platform_hint: x11

これは起動時に ELECTRON_OZONE_PLATFORM_HINT へ橋渡しされます（明示的な環境変数のほうが優先されます）。引き換えがあって、X11 はマウスを無視したウィンドウを元に戻せないため、HUD はクリックが通り抜けるものではなく実体のあるウィンドウのままになります。KDE の構成によっては X11 の ozone バックエンドでキーボードが壊れるという報告もあります。常に最前面が必要でないかぎり、このヒントは auto のままにしてください。

WSLg（WSL2 から Windows の GPU を使う）

ローカルの WSLg の下では、Hermes は --ozone-platform=wayland を付けて起動します。XWayland で最大化したウィンドウがずれ、マウスの当たり判定もずれる問題（microsoft/wslg#1015）を避けるためです。プラットフォームはプロセスの起動時、Electron がアプリケーションの JavaScript を読み込む前に決めなければなりません。明示的な --ozone-platform=x11 と desktop.ozone_platform_hint: x11 はこれまでどおり使えます。WSLg では、アプリが最小化・最大化・閉じるの操作を自前で描きます。

hermes gui を WSL2 の中で走らせたとき、/dev/dxg があって Mesa の d3d12_dri.so が入っていれば、ランチャーは Electron に GALLIUM_DRIVER=d3d12 を設定します。llvmpipe のソフトウェアラスタライザではなく Windows の GPU で描画させるためです。環境にすでに GALLIUM_DRIVER・MESA_LOADER_DRIVER_OVERRIDE・LIBGL_ALWAYS_SOFTWARE・LIBGL_DRIVERS_PATH を明示しているなら、そちらには手を付けません（たとえば GALLIUM_DRIVER=llvmpipe hermes gui ならソフトウェア描画のままです）。

起動フラグとレンダラーのヒープ上限

desktop.* の2つのキーは、hermes desktop でもスタートメニューのショートカットでも Linux の .desktop エントリでも、どの経路でも起動時に Chromium まで届きます（アプリは最初のウィンドウが開く前に config.yaml からこれらを読みます）。

desktop:
  electron_flags: ["--ozone-platform=x11"]   # extra Chromium switches; a single string is split on spaces
  renderer_max_old_space_mb: 2048            # V8 heap ceiling for the chat renderer; 0 = Chromium default

renderer_max_old_space_mb は --js-flags=--max-old-space-size=N として適用され、すでに渡している --js-flags とは統合されるので、互いを打ち消しません。とても長くツールを多用したセッションが、レンダラーを端末の余力より先へ押し出してしまうときに設定してください。そうすればレンダラーは自分の上限に当たって読み込み直し（1分あたり3回までに抑えられます）、端末全体が固まらずに済みます。

どちらのキーも、ここに示したとおりに書かなければなりません。トップレベルの desktop: キーの下にスペース2つのインデント、ブロック形式のリストなら - の前にスペース4つです。

desktop:
  electron_flags:
    - "--ozone-platform=x11"
    - "--js-flags=--expose-gc"

ウィンドウが開く前に読むこの部分は、Hermes の他の場所が使う完全なパーサーではなく、小さな YAML のサブセットです。アプリが何かを読み込む前に動かなければならないからです。他のインデントは YAML としては正しくてもここでは無視され、そうなったときアプリは起動時に desktop.electron_flags / desktop.renderer_max_old_space_mb were ignored と記録し、Chromium の既定値で立ち上がります。

設定と初回セットアップ

YAML を書く代わりに、きちんとした UI からプロバイダー・モデル・ツール・資格情報を管理できます。初回のセットアップは、数秒で最初のメッセージまで連れていってくれます。設定のページはプロバイダーとキー、モデルの選択、ツールセットの構成、MCP サーバー、ゲートウェイ、セッション管理をカバーします。

• プロバイダーの設定ページ — 推論プロバイダーを管理する専用の場所で、プロバイダーごとにサインインして資格情報を保存するための Accounts / API キーの UI があります。Accounts、API キー、Custom Endpoints は設定の Applies to の選択を共有します。資格情報の読み書き、OAuth アカウントの削除、カスタムエンドポイントの保存とテスト、ここから始めたサインインは、いま開いているチャットのプロファイルではなく、選択されたプロファイルに向かいます。サインインの流れは、資格情報の保存とモデルの選択までその対象を保ちます。Applies to を変えると、保存していない資格情報の下書きは捨てられます。サインインを閉じるとポーリングは中止され、遅れて届いた結果は無視されます。すでに送られた資格情報の書き込みは、元のプロファイルで完了することがあります。外部で管理される CLI の資格情報はその CLI 自身のものを使うので、このプロファイル選択の対象外です。この中の Local Models ビューは、端末上の llama.cpp ランタイムを導入して管理します。Local Models を参照してください。
• メニューにすべてのプロバイダーとモデルが並ぶ — GUI は、hermes model が知っているプロバイダーとモデルをすべて出します。誰かが選んだ一部ではなく、CLI と同じカタログから選べます。
• API モードを選べるカスタムエンドポイント — Settings → Providers → Custom Endpoints には API Mode の選択（Auto-detect・Chat Completions・Responses API・Anthropic Messages）があります。カスタムプロバイダーに対して hermes model が出すのと同じ選択肢です。これは config.yaml に providers.<id>.api_mode として保存されるので、Responses しか受けないホストや Anthropic 互換のホストが /chat/completions に呼ばれることはもうありません。Test は /v1/models を叩くだけでなく、実際に使う経路を確かめます。固定したモード（あるいは Auto-detect が決めたモード）のルートに1トークンのリクエストを送り、ホストがそれを受けないときはその経路の名前を添えて失敗します。Test はまた、ゲートウェイが /v1/models で広告するエイリアスのメタデータ（canonical_model、reasoning_effort）も保ちます。gpt-5.6-sol-high のようなエイリアスを選ぶと、正規のモデルが保存され、その effort が agent.reasoning_overrides の下に固定されます。
• xAI Grok の OAuth — Grok はランチャーで一級の OAuth プロバイダーとして扱われます。他の OAuth プロバイダーと同じくブラウザの流れでサインインします。
• ツールバックエンドの導入を GUI から — ターミナルへ降りずに、ツールバックエンドのセットアップ後の導入手順をアプリから直接実行できます。ターミナルのバックエンド選択で Needs setup と印の付いたものを選ぶと、まず確認を求められます。断れば、いま選ばれているバックエンドがそのまま残ります。
• ターミナルのフォント選択 — Settings → Appearance でインストール済みのフォントを選べます。MesloLGS NF のような Nerd Fonts は、対話用のターミナルでもエージェント用のターミナルでも Powerlevel10k の区切りやアイコンを描きます。この設定はプロファイルごとに保存されます。
• Reasoning Blocks — Settings → Chat → Reasoning Blocks（config.yaml の display.show_reasoning）で、モデルの思考をトランスクリプトに出すか隠すかを決めます（切ると答えだけが出ます）。開いているチャットは、設定が保存された時点で更新されます。コンポーザーで /reasoning hide や /reasoning show と打っても同じ設定が切り替わり、開いているトランスクリプトもすぐ追従します。
• 起動時に前のチャットを開く — 既定では、冷えた状態から起動しても続きから始まります。Settings → Appearance で切る（または config.yaml に display.resume_last_session: false を書く）と、いつも新しいチャットから始まります。ディープリンクや明示的な行き先は、どちらの設定でも上書きされません。
• 補助モデルの警告 — 補助タスク（タイトル付け、要約などの手伝い）が別のプロバイダーに固定されたまま、メインのモデルを新しいプロバイダーへ切り替えると、アプリが警告します。気づかないうちに作業が2つのプロバイダーへ分かれてしまわないようにするためです。
• タスクごとの推論 effort — Settings → Model → Auxiliary models の各行には、プロバイダーとモデルの選択の隣に推論の選択があります。段階を指定するか、Off か、inherit · main model effort（既定で、そのタスクの上書きを外します）です。これは config.yaml に auxiliary.<task>.reasoning_effort として保存され、hermes model が書くのと同じキーで、設定されていれば行の要約にも出ます。圧縮やタイトル付けのような頻繁に走る手伝いを低い推論や推論なしで回し、メインのエージェントは高いままにしておく、といった使い方ができます。
• VS Code Marketplace のテーマ — 組み込みのテーマのプリセットに加えて、外観の設定には VS Code Marketplace をその場で検索する機能があります。好きなカラーテーマを選べば、アプリがダウンロードし、変換し、デスクトップのテーマとして導入します。同じ取り込み機能はコマンドパレット（*Install theme*）からも使え、取り込んだテーマは外観の設定から削除できます。
• 端末をスリープさせない — Settings → Advanced → Keep computer awake は端末が眠るのを止めるので、長時間や一晩がかりのエージェントの作業が止まりません（画面が暗くなることはあります）。While working はターンの実行中だけ端末を起こしたままにし、作業が終わるか失敗すれば通常どおりスリープさせます。Always は Hermes を開いているあいだずっと起こしたままにします。誰もモードを選んでいない端末では While working が既定です。Off にしていて、時間で入るスリープがターンを中断した場合は、復帰したときに Hermes が Keep awake while working を一度だけ勧めます。ふたを閉じたりスリープを選んだりすれば端末は眠りますし、バッテリーで動いているときは Windows が独自のタイムアウトで眠らせることもあります。これは端末ごとの設定です。

初回のセットアップは統一されたオーバーレイのデザインシステムで作り直されました。Choose provider later を選べば、プロバイダーの設定を飛ばして先にアプリへ入れます。

プロファイルごとの設定: 「Applies to」の範囲

プロファイルが2つ以上あるとき、設定ファイルに書き込まれる設定ページ（Model、Workspace、Safety、Memory & Context、Voice、Chat、Advanced、Tools & Keys）に加えて、Providers → Custom Endpoints と Messaging のオーバーレイには、共通の Applies to のチップ列が上部に出ます。ここで、編集がどのプロファイルに向かうかを選びます。

• 既定の選択はいま使っているプロファイルに追従します。これまでとまったく同じで、使っているプロファイルをそのまま編集する形です。
• 別のプロファイルを選べば、アプリ全体を切り替えずに*そのプロファイルの*設定を見て編集できます。この選択は設定ページを移動しても保たれます。
• アプリの使用中プロファイルを切り替えると選択はリセットされるので、前に選んだプロファイルへ編集が静かに落ち続けることはありません。
• プロファイルが2つ未満のときは、チップ列そのものが出ません。

（Gateways のページはプロファイルの扱いが異なり、Per-profile overrides の小節で扱います。Capabilities と Scheduled Jobs のビューはそれぞれ独自の範囲選択を持ちます。）

管理用のペイン

ターミナルへ降りずに済むよう、アプリは Hermes のより広い管理機能も表に出しています。

• Skills — スキルを見て回り、導入し、管理します。Skills のタブには、導入済みのスキルが有効／無効の切り替えとともに並び、その下に Hermes に同梱された任意スキルの組み込みカタログ全体が並びます。どの項目にも1クリックの Install ボタンがあり、導入が終わるとその行は導入済みの一覧へ移ります。公開の Skills Hub にある Install in Hermes のボタンは hermes://skill/install?identifier=... のリンクを開き、確認したあと同じ仕組みで導入します（スキルのリンクを参照してください）。
• メモリグラフ（Star Map） — チャットで /journey（別名 /learning、/memory-graph）と打つと、学んだスキルとメモリの時間を追った星座図が開き、再生用のつまみで動かせます。ノードはこのパネルから直接編集も削除もできます（スキルは保管に回り、メモリは削除されます）。Learning Journey を参照してください。
• Cron — 予約ジョブを見て管理します。All profiles を入れると、すべてのプロファイルのジョブがまとめて並びます。ジョブの実行履歴と操作（一時停止・再開・編集・削除）は、どのプロファイルを使っていても、常にそのジョブを持つプロファイルに向かいます。
• Profiles — Hermes のプロファイル（設定・スキル・セッションが分離されています）を切り替えます。
• Messaging — ゲートウェイのチャンネルを設定します。Telegram には Quick setup のカードがあります。Create with QR を押してコードを読む（またはリンクを開く）と、Telegram 側で Hermes がボットを作り、許可リスト用にあなたのユーザー ID を検出し、資格情報を保存し、ゲートウェイを再起動します。資格情報の保存・消去・有効化の切り替えを行うと、ゲートウェイが実際に再起動するまで Restart now の帯がページに残ります。再起動に失敗しても帯は残るので、やり直したり手で再起動したりできます。
• Agents と Command Center — 複数エージェントでの作業を束ねるための画面です。

Bot Mode（組み込み）

Bot Mode はアプリに同梱され、既定で有効です。「エージェント1人につき チャット1つ」の名簿で、Hermes のプロファイルがそれぞれ、自分の アバター（図形の顔、アップロードした画像、AI が描いた肖像、ピクセルの ペット）と、自分だけの正規の Bot Chat の会話、そして自分の Routines （Hermes の cron に支えられた繰り返しのタスク）を持つボットとして並びます。名簿は左の サイドバーに、会話の隣のタブとして置かれます。セッション一覧の下に 2つ目のペインを積むのではなく、Sessions | Bots のタブの 帯という形です。古い積み重ね型のレイアウトを引き継いだ 環境は、一度だけ自動でタブの帯へ移されます。自分でペインを配置していた 場合は、そのレイアウトには手を付けません。Cronjobs（Routines）のペインがチャットの隣に出るのは Bots のタブが選ばれている間だけで、Sessions へ戻すと消えます （古いデスクトップのビルドでは、常に見えたままです）。

新しいエージェントは名簿から作ります。 名前／肩書き／説明に加えて、能力のすべて（モデル、SOUL、スキル、ツールセット、MCP サーバー）を 開いて設定できる Advanced があります。ボットは セクションにまとめられますし、何体かが議論するグループチャットも開けます。 グループチャットは名簿の中に、Discord のような独立した行として並びます。重なった メンバーのアバター、メンバー数、部屋の最新の発言のプレビュー、 「あなたを待っています」のバッジが付き、ボットの行と同じピン留め＋新しさの 順序で混ざります。グループの行をクリックすると、その部屋が メインのチャットウィンドウを占めるタブとして開きます（古いデスクトップのビルドでは、 ボットのサイドパネルの中で開きます）。

ボット同士も会話します。どのチャットでも @researcher have a look at this と打てば いま話しているボットがそのメッセージを渡して結果を持ち帰りますし、ボットは 互いの Bot Chat へ直接届きます（hermes -p <bot> chat）。バックエンドは 各ボットの正規の Bot Chat のセッションへ、メッセージのやり取りの作法を 自動で教えます（設定 agent.bot_mode_protocol、既定は有効）。仲間のボットが CLI からヘッドレスで開いた場合も同じです。おかげでボット同士の 返信や引き継ぎは SOUL.md に手を入れなくても動き、ふだんの セッションはそのまま変わりません。

Bot Mode のセッション、つまり各ボットの正規の Bot Chat と、グループチャットの メンバーごとのセッションは、全体の Sessions サイドバーからは常に隠されています。 自分の会話に混ざるのではなく、Bots のペイン（名簿の行、部屋のビュー、各ボットの セッション一覧）の中にあります。

使わないボットはしまっておけます。ボットの行を右クリック → Hide Bot です。隠したボットは名簿から消えますが働き続けます。@メンションは これまでどおり届きますし、グループチャットの所属もそのままです。1体でも 隠していると Bots の見出しに目のアイコンが出て、押すと隠したボットが薄い表示で その場に現れます（右クリック → Unhide Bot で戻せます）。隠したボットに未読の動きがあると、 目のアイコンに点が付きます。隠しているかどうかは そのボットのプロファイルに保存されるので、端末をまたいでも 付いてきます。

不要ですか？ Capabilities → Plugins → Bots で Desktop のスイッチを切ってください。名簿も Routines のペインもコンポーザーの中間処理もその場で解除され、再起動は要りません。

エージェントの作成（複数の端末にまたがる Create on の 選択を含む）、接続をまたいだ名簿、ボット同士のメンション、グループ チャットで誰が答えるかの決まり方まで含めた案内は Bot Mode: A Roster of Agents にあります。

キーボードとナビゲーション

• コマンドパレット — Cmd+K か Cmd+P（Windows/Linux では Ctrl+K / Ctrl+P）を押すと、キーボードだけで操作と移動ができます。任意のページや設定の節を開く、タイトルや id でセッションへ飛ぶ、モデル／テーマ／配色を切り替える、ターミナルを開く、ゲートウェイを再起動する、Hermes を更新する、などです。
• 割り当てを変えられるショートカット — Settings → Keyboard Shortcuts（または Cmd/Ctrl+/）でショートカットのパネルが開き、ほとんどの割り当てを変えられます。プロファイルの切り替え、セッションの移動、表示の切り替え、そしてデスクトップのプラグインが追加したショートカットも対象です。重複した割り当ては衝突として印が付きます。覚えておくとよい既定をいくつか挙げると、Cmd/Ctrl+N で新しいセッション、Cmd/Ctrl+. で Command Center、Cmd/Ctrl+, で設定、Cmd/Ctrl+Shift+F でセッションの検索、Cmd/Ctrl+1–9 でポインターの下にあるペイン（またはフォーカス中のペイン）の N 番目のタブへの切り替え（どのペインにもタブ列がないときはプロファイルの切り替え）、Shift+X で明暗の切り替えです。
• 拡大縮小のショートカットを自分で決める — 画面を半段階ずつ拡大縮小できるので、文字の大きさを細かく合わせられます。
• UI の言語切り替え — アプリの表示言語をアプリ内で変えられます。英語、簡体字中国語（zh-Hans）、繁体字中国語（zh-Hant）、日本語、アラビア語（RTL）、ロシア語に対応します。

セッションとプロファイル

• セッション一覧の刷新 — 保管の機能と全体的な整理の仕組みを備えた一覧に作り直され、数が増えても扱いやすいままです。
• id でセッションを探す — 特定のセッションを id から直接見つけられます。
• 複数プロファイルのセッションを同時に — 複数のプロファイルにまたがるセッションを同時に走らせ、プロファイルをまたぐ @session のリンクで別のプロファイルのセッションを参照できます。
• プロファイルの書き出しと読み込み — 環境まるごとを1つのファイルとして渡せます。⌘K → Export profile…（またはレールのプロファイルの四角を右クリック）で、スキル・メモリ・ペルソナ・cron・プラグイン・設定を含む .tar.gz が書き出されます。API キーは取り除かれます。デスクトップから書き出すと、見た目と画面の設定（スキン、明暗のモード、独自のテーマ、そのプロファイルのレールの色、ウィンドウのレイアウト）も同梱されるので、読み込んだプロファイルは送り主が見ていたとおりの姿で届きます。読み込みは ⌘K → Import profile… か、レールの + の隣のボタンから行い、上書きの内容が適用されて新しいプロファイルへ入ります。同じアーカイブは、チャットの /export / /import でも、シェルからの hermes profile export / import でも使えます。Export and import a profile file を参照してください。

更新

アプリはバックグラウンドで更新を確認し、用意ができたらワンクリックで更新できるようにします。

バックグラウンドの確認は、GitHub の API にブランチの先頭を尋ねます。匿名の GitHub へのリクエストはネットワークアドレスごとに1時間 60 回までなので、共有の回線（オフィスの NAT、VPN、プロキシ）では、この端末がほとんど使っていなくても GitHub API rate limit reached と報告されることがあります。1時間 5,000 回の枠を使うために、確認は次の順で最初に見つかった資格情報を使います。

1. アプリを起動した環境の GITHUB_TOKEN、次に GH_TOKEN。リクエストのたびに読まれ、保存はされません。
2. GitHub CLI 自身のログイン（gh auth token）。Dock や Finder、デスクトップのランチャーから起動したアプリはシェルの変数を持たない最小限の環境を引き継ぐので、この段が効きます。gh は PATH と、よくある導入先（Homebrew、/usr/local/bin、~/.local/bin、Windows の GitHub CLI インストーラー）から探されます。答えはアプリが再起動するまでキャッシュされるので、gh が走るのはセッションにつき多くても一度です。
3. 匿名。

GitHub が拒否した資格情報（HTTP 401 — 期限切れか失効）は、その出どころを添えて desktop.log に一度だけ記録され、トークン自体は書かれません。そのリクエストは匿名でやり直されます。更新を適用するときに使うのは API ではなく git なので、この影響は受けません。

ローカルでの更新中は、詳細なビルドの出力が使用中のプロファイルの logs/update.log へ流れます。切り離された --gateway の更新も含みます。ターミナルには 出ませんが、ビルドが終わる前でも切り分けに使えます。Windows の 引き継ぎは、このログに新しい出力が増えることを進捗とみなします。何も出力しない子プロセスは、 それでも無反応の監視の対象です。プロセスが生きていることだけでは その監視はリセットされませんし、更新を取り消してもビルドの終了を待つことはありません。

デスクトップアプリと、それが話しかける Hermes のバックエンドは、別の時計で更新されます。アプリのパッケージはこの端末にあり、バックエンドはそれが動いている場所にあります。更新の対象が複数あるとき（リモートのゲートウェイがある、あるいは複数のゲートウェイを登録している）、更新のための操作（About パネルの Update now、⌘K の Update Hermes の行、更新の準備ができたことを知らせるトースト）はすべてを更新します。まず接続中のバックエンド、次に対象となる他の登録済みゲートウェイすべて（Hermes Cloud の項目はプラットフォーム側が管理するので飛ばされます）、そして最後にデスクトップアプリ自身です。クライアントの更新を当てるとアプリが起動し直すためです。1台だけの環境では、ボタン1つという体験のままです。

バックエンドを更新したあとは、アプリが自分のバージョンも確認し直し、GUI がまだ遅れていればワンクリックの Update desktop app を添えて知らせます。リモートのバックエンドを更新した結果、古いデスクトップのビルドに気づかず取り残される、ということが起きないようにするためです。

手動での更新手順も GUI で使えます。

アンインストール

アプリが管理しているインストールでは、Settings → About → Danger zone を開いて、どこまで消すかを選びます。

• Uninstall Chat GUI only — デスクトップアプリとそのデータを消します。Hermes のエージェント、設定、チャットは残ります。（hermes uninstall --gui と同じです。）
• Uninstall GUI + agent, keep my data — アプリとエージェントを消しますが、設定・チャット・秘密情報は将来の再インストールのために残します。（hermes uninstall と同じです。）
• Uninstall everything — アプリ・エージェント・すべてのユーザーデータを消します。（hermes uninstall --full と同じです。）

仕上げのためにアプリは閉じます（後片付けは終了後に走ります。動いているアプリ本体と自身の venv を消せるようにするためです）。ローカルにエージェントが入っていない場合、エージェントを消す選択肢は自動的に隠れます。

Nix、同梱版のパッケージ、そのほか外部が所有するインストールでは、これらの操作は隠れます。それらは、それぞれのパッケージマネージャーか OS から削除してください。アプリは、リモートのバックエンドの更新状況とは関係なく、ローカルのパッケージを自分が所有しているかを確かめます。所有を確認できない場合、アンインストールの操作は出ません。

自分で管理しているインストールなら、同じことはターミナルからもできます。GUI だけなら hermes uninstall --gui、エージェントも消すなら hermes uninstall か hermes uninstall --full です。

GUI の後片付けを試しに見るには hermes uninstall --gui --dry-run を使います。消す対象を並べるだけで、確認も削除もせずに終わります。--yes を一緒に付けても同じです。

チェックアウトの中で一度デスクトップアプリをビルドしていれば、hermes update はそのアプリも最新に保ちます。アプリを一度も開かないサーバーでも同じです。画面のない Linux ホストや、デスクトップアプリ自身の Node の依存関係が入らない場合（たとえば node-pty には古すぎるコンパイラ）でも、更新は TUI と Web UI をビルドし、デスクトップのビルドは未了だと報告して hermes uninstall --gui を勧めます。そのアンインストールのあとの更新では、デスクトップアプリは飛ばされます。

CLI 早見表: hermes desktop

CLI から起動するなら hermes desktop を実行するだけです。既定では、ワークスペースの Node の依存関係を入れ、いまの OS 向けに展開済みの Electron アプリをビルドしてから、そのパッケージ済みの成果物を起動します。

Linux では、起動のたびに $XDG_DATA_HOME/applications/hermes.desktop（既定では ~/.local/share/applications/hermes.desktop）が更新され、Hermes がアプリケーションのメニューに出ます。手で書き換えたエントリを守りたいときは、更新を止めてください。

hermes config set desktop.manage_launcher_entry false

エントリが無ければ作られます。このフラグが止めるのは、hermes desktop がすでにあるエントリを書き換えることだけです。

アプリケーションの一覧やメニューから Hermes を起動したとき（ランチャーが DESKTOP_STARTUP_ID を設定します）、エントリが書かれるのはウィンドウが画面に出たあとです。ウィンドウが出る前にアプリが終了した場合、そのときは何も書かれません。次にターミナルから起動するか、更新後に起動し直すか、一覧から起動してウィンドウが出たときに書き込まれます。GNOME Shell の一部のバージョンは、起動中に .desktop ファイルが変わったアプリを見失います（プロセスが終わるまでではなく、起動の通知が完了するかタイムアウトするまでその状態を保ちます）。それが後になってセッション全体を巻き込んで落ちることがあるので、ウィンドウを待つことでそれを避けています。ターミナルからの起動と、更新後の起動し直しでは、これまでどおりすぐ書き込まれます。

仕組み

パッケージ済みのアプリには、Electron のシェルとネイティブな React のチャット画面が入っています。初回の起動時には、Hermes Agent のランタイムを HERMES_HOME（~/.hermes、Windows なら %LOCALAPPDATA%\hermes）へ導入できます。これは CLI で入れたときとまったく同じ配置で、だからこそ両者は入れ替えて使えます。同梱版のアプリは、中に含まれているバックエンドを使います。同梱のバックエンドが無い場合、解決は HERMES_DESKTOP_HERMES_ROOT を尊重し、次に開発用のチェックアウト、次に Nix のようなパッケージャー向けの明示的な HERMES_DESKTOP_HERMES によるコマンドの上書き、最後に使える状態の管理下の導入、の順に見ます。コマンドの上書きを管理下の導入より優先するのは、Nix のデスクトップが古い書き換え可能なランタイムを黙って起動しないようにするためです。React のレンダラーが話す相手は、そのプロファイルのゲートウェイです。ローカルのプロファイルを初めて使うとき、アプリは hermes gateway ensure を実行します。これはそのプロファイルを受け持つゲートウェイにつなぎ、無ければ起動します（すでに導入済みの systemd/launchd のサービスがあればそれを、無ければ切り離したデーモンとして。ensure がサービスを導入することはありません）。プロファイルに gateway.standalone: true が付いていない限り、1台のホストにつき1つのゲートウェイがすべてのプロファイルを受け持ち、デスクトップは使い捨てのチケットで /api/ws を通してつなぎます。hermes chat、TUI、メッセージングのチャンネルが使うのと同じプロセスです。このゲートウェイはアプリの寿命とは結び付いていません。アプリを終了しても動き続け、使われていないからといって止まることもありません。止めるには hermes gateway stop（または Settings にあるゲートウェイの操作）を使います。デスクトップアプリは自己完結していて、別の hermes serve のプロセスを必要とせず、web dashboard を開くことも必要とすることもありません。導入・バックエンドの解決・自己更新の処理は、Electron のメインプロセスにあります。

リモートバックエンドへの接続

既定では、アプリは自分のローカルのバックエンドを起動して面倒を見ます。代わりに、別の端末で動いている Hermes のバックエンド（VPS、自宅のサーバー、Tailscale の向こうの Mini など）を向かせることもできます。

接続にまつわるものはすべて1つの設定ページ、Settings → Gateways にあります。（古いビルドでは Gateway と Connections の別々のページに分かれていました。いまは統合され、古い ?tab=connections のディープリンクは統合後のページへ転送されます。）

Settings → Gateways → Connection mode に、ローカルのゲートウェイ以外の選択肢が並びます。

• Remote gateway — 自分で動かしている hermes serve のバックエンドの URL を入れてサインインします。この節のこれ以降で扱うのはこのモードです。
• Hermes Cloud — Hermes Cloud に一度サインインして、アカウントにあるエージェントから選びます。URL を貼る必要はありません。アプリがエージェントを見つけ（アカウントが複数の組織にまたがる場合は組織の選択も出ます）、1つにつなぐとセッションが自動的にそちらへ移ります。つながっている間、ステータスバーにクラウドの接続が表示されます。

ゲートウェイへの接続は端末単位です。Gateways のページは、このデスクトップがどのゲートウェイのバックエンドにつなげるかを管理し、プロファイルは、つないだゲートウェイ*から*見つかります。セッションは一度に1つのゲートウェイを選び、その隣のプロファイルのレールは、そのゲートウェイ上で見つかったプロファイルを選びます。

複数接続の登録簿

同じ Settings → Gateways のページの下のほうにある Registered gateways は、アプリが知っているすべての Hermes ゲートウェイ（ローカルのランタイム、いくつでもあるリモートのゲートウェイ（LAN、Tailscale、インターネット）、Hermes Cloud のインスタンス、SSH のホスト）を名前付きの一覧として管理し、まとめて1か所に保存します。サイドバーのプロファイルのレールの右端にあるプラグのボタン（Connect another Hermes gateway…）か、⌘K → Gateways から開けます。統合されたエージェントの名簿、@name-device の呼び名、環境全体の更新、プラグイン SDK の機能まで含めた案内は Connecting Desktop to Many Hermes Instances にあります。

• 接続にはそれぞれ固有の名前が要ります（「Homelab」「Work laptop」のような端末の名前）。同じプロファイル名が複数の登録済みゲートウェイにあるとき、画面上では @profile-device の形（例: @research-homelab）で区別されます。
• ゲートウェイは Sessions サイドバーから切り替えます。 ゲートウェイが2つ以上登録されると名前付きのゲートウェイ選択が現れ、登録簿がどれだけ大きくなっても、ゲートウェイがプロファイルのように見えてしまうことはありません。隣のプロファイルのレールにはそのゲートウェイのエージェントだけが並び、そこで最後に使ったプロファイルを覚えています。プロファイルが多いときは、そちらだけが独立して畳まれます。
• プロファイルのレールを隠す。 プロファイルがワークスペースではなくボットなら、サイドバーの下端にある色付きの四角の帯はセッション一覧と重複します。Sessions のビューのメニュー（Profile rail）、シェルの右クリックメニュー、⌘K → Toggle profile rail のいずれかで消せます。隠している間は、ステータスバーのゲートウェイ選択の隣に Profiles のドロップダウンが出て、同じ選択肢（このゲートウェイのプロファイル、他のゲートウェイのエージェント、New profile、Import profile…、Manage profiles…）が並ぶので、プロファイルを切り替える入り口は必ず残ります。
• 再起動後に何を開くかを選ぶ。 Open on launch は、これまでと同じ Primary gateway を既定のままにもできますし、Last used のゲートウェイにつながったあとそれを再開させることもできます。この設定はアプリケーションのバンドルの外に保存され、Desktop の更新をまたいで残ります。
• 接続の追加・編集・削除・テストをこのパネルから行えます。Add の流れは4種類すべて（Local、Hermes Cloud、Remote gateway、SSH）に対応します（アプリが管理するローカルの項目がある間、Local のボタンは押せません。クラウドの追加については、上のサインインと検出の流れへ案内が出ます）。ローカルの項目はアプリが管理していて、削除できません。Test は、その接続自身の HTTP と WebSocket の脚を直接叩いて確かめます。
• 重複は保存の時点ではじかれます。local の項目は常に1つだけです。リモートとクラウドの項目は、正規化した URL（前後の空白を落とし、末尾のスラッシュを外し、小文字にしたもの）で、両方の種類をまたいで重複が除かれます。SSH の項目は、正規化した user@host:port とリモートのプロファイルで判定されます。
• 登録簿を備えたビルドを初めて動かしたとき、いまの設定は自動的に取り込まれます。現在のグローバルな接続と、従来のプロファイルごとの上書きは、名前の付いた項目になります。従来の設定ファイルはそのまま残るので、古いビルドも動き続けます。
• クラウドの項目は、手で打った URL からではなく、上の Hermes Cloud のサインインと検出の流れから来ます。
• トークンは OS のキーリングで暗号化して保存されます（キーリングのない Linux では、平文で保存することを明示的に選べます）。

横並びの経路分けは実際に動いています。登録されたゲートウェイはそれぞれ、必要になったときに自分のバックエンドとソケットをつなぎ（接続とプロファイルの組でキーが分かれます）、プラグイン SDK は統合されたエージェントの名簿（host.agents() / host.ensureAgent()）を出し、Gateways のページの Update all instances は対象となるすべてのゲートウェイへ hermes update を一斉に投げます。Hermes Cloud の項目は飛ばされ（プラットフォームが更新します）、インスタンスごとに自分の結果を報告します。

接続には2つの側面があります。バックエンド側では認証プロバイダーで守り、アプリ側ではバックエンドの URL を入れてサインインします。バックエンドをループバック以外のアドレスに割り当てると自動的に認証のゲートが働き、設定したプロバイダーがデスクトップアプリを通す役目を負います。

バックエンドがどこにあるかでプロバイダーを選んでください。

• OAuth（Nous Portal） — 自分の端末の外から届くものにはこちらを推奨します。 ログインは Nous のアカウントに照らして検証されるので、VPS、公開されたホスト、そのほかどんなリモートのバックエンドにも向いています。hermes dashboard register（または Portal の /local-dashboards のページ）でダッシュボードを登録して OAuth のクライアントを用意し、アプリから Sign in with Nous Research でサインインします。自前の ID プロバイダーを動かしているなら、自己ホストの OIDC プロバイダーでも同じように使えます。
• ユーザー名とパスワード — ローカルや信頼できるネットワークでのみ。 バックエンドが同じ信頼できる LAN にあるか、VPN（Tailscale など）越しにしか届かないときの、いちばん手軽な選択肢です。外部の ID プロバイダーを使わずに共有の資格情報1組で守るだけなので、公開インターネットに晒したダッシュボードには使わないでください。そこでは OAuth を選んでください。

この節の残りではユーザー名とパスワードの経路を示します。信頼できるネットワークでいちばん早く立ち上げられるからです。OAuth の経路については Web Dashboard → Default provider: Nous Research を参照してください。

バックエンド側（リモートの端末）で

ユーザー名とパスワードを設定し、届くアドレスに割り当ててバックエンドを起動します。資格情報は ~/.hermes/.env（パーミッション 0600 の秘密情報のファイル）に置きます。

# 1. Set the dashboard login credentials.
cat >> ~/.hermes/.env <<'EOF'
HERMES_DASHBOARD_BASIC_AUTH_USERNAME=admin
HERMES_DASHBOARD_BASIC_AUTH_PASSWORD=choose-a-strong-password
# Recommended: a stable signing secret so sessions survive restarts.
# Without it a random key is generated per boot and you'll be logged out
# on every restart.
HERMES_DASHBOARD_BASIC_AUTH_SECRET=$(openssl rand -base64 32)
EOF
chmod 600 ~/.hermes/.env

# 2. Run the backend bound to a reachable address. The non-loopback bind
#    engages the auth gate; the username/password provider handles login.
hermes serve --host 0.0.0.0 --port 9119

デスクトップアプリからつなげるようにしておきたい間は、その hermes serve のプロセスを動かし続けてください。止まれば、アプリはバックエンドに届かなくなります。systemd、tmux、あるいは好きなプロセス管理の仕組みの下で動かし、ログアウトや再起動をまたいでも残るようにしてください。

これとは別に、メッセージングのチャンネルに頼っているなら、リモートのホストでゲートウェイが動いていることを確かめてください。デスクトップアプリが話す相手は hermes serve のバックエンドですが、Telegram／Discord／Slack のゲートウェイのセッションは別のプロセスで、自分で起動して動かし続けるものです。ゲートウェイの設定は Messaging を参照してください。

平文のパスワードを置いたままにしたくないですか？ 代わりに HERMES_DASHBOARD_BASIC_AUTH_PASSWORD_HASH に scrypt のハッシュを設定してください。ハッシュは python -c "from plugins.dashboard_auth.basic import hash_password; print(hash_password('PW'))" で計算します。設定できるものの全体（config.yaml のキー、すべての環境変数、レート制限）は Web Dashboard → Username/password provider にあります。

バックエンドを systemd のサービスとして動かしますか？ ユニットに EnvironmentFile=%h/.hermes/.env を与えて、起動時に資格情報が環境へ入るようにしてください。

アプリ側で

Settings → Gateways → Remote gateway を開きます。

1. Remote URL — http://<backend-host>:9119（リバースプロキシを前に置いているなら /hermes のようなパスの接頭辞も使えます）
2. Sign in — バックエンドがどのプロバイダーを掲げているかをアプリが見分けて、ボタンを合わせます。ユーザー名とパスワードのバックエンドなら、資格情報の入力欄を開く Sign in のボタンが出ます（手順1の資格情報を入れてください）。OAuth のバックエンドなら Sign in with <provider>（例: *Sign in with Nous Research*）が出て、そのプロバイダーのブラウザでのサインインが走ります。どちらでも、最終的にアプリはバックエンドに対して認証済みのセッションを持ちます。
3. Save and reconnect — デスクトップの画面をリモートのバックエンドへ切り替えます。セッションは自動的に更新され、HERMES_DASHBOARD_BASIC_AUTH_SECRET を設定してあれば再起動をまたいでもサインインしたままです。

UI を使わずに、アプリを起動する前に環境変数 HERMES_DESKTOP_REMOTE_URL でバックエンドの URL を設定することもできます（アプリ内の設定より優先されます）。サインインは引き続き Gateways の設定パネルから行います。

困ったときは

Windows ARM64 でウィンドウのコンテキストが使えない

インストールされている get-windows パッケージに、動作する win32-arm64 のネイティブバインディングが含まれているか確かめてください。これがないと、read_window_below と HUD のウィンドウ コンテキストは、ほかのアプリのウィンドウを列挙できません。エラーと HUD のログには、 この対処の案内と一緒に、もとになった失敗の理由が残ります。

バインディングが使えない場合は、x64 版のデスクトップビルドを Windows の エミュレーションで動かすか、対応するネイティブバインディングを含むカスタムビルドを使ってください。エージェントの バックエンドを替えても、macOS の画面の権限を与えても、Windows のバインディングがないことは 解決しません。列挙はデスクトップアプリを動かしているコンピューターの上で行われるからです。なお、この 診断は ARM64 でのネイティブなウィンドウ列挙に対応するものではありません。

• サインインが 401 や「Invalid credentials」で失敗する — ユーザー名かパスワードが、バックエンドの HERMES_DASHBOARD_BASIC_AUTH_USERNAME / HERMES_DASHBOARD_BASIC_AUTH_PASSWORD と一致していません。バックエンドは、知らないユーザーでもパスワード違いでも同じ一般的なエラーを返すので（どちらが違うかは分かりません）、両方を確かめてください。ゲートが効いているかは curl -s http://<host>:9119/api/status | jq '.auth_required, .auth_providers' で確認できます。true が返り、"basic" が含まれているはずです。
• 「Sign in」のボタンが出ず、代わりにセッショントークンを求められる — バックエンドのユーザー名とパスワードのプロバイダーが働いていません。/api/status の auth_providers に "basic" が並ばないはずです。ユーザー名とパスワード（またはパスワードのハッシュ）の両方が ~/.hermes/.env に設定されていること、そしてダッシュボードのプロセスが実際にそれを読み込んでいることを確かめてください。
• 再起動のたびにサインアウトされる — HERMES_DASHBOARD_BASIC_AUTH_SECRET に固定の値を設定してください。これがないと、トークンの署名鍵が起動のたびに作り直され、すべてのセッションが無効になります。
• 接続を拒否される／タイムアウトする — バックエンドが 127.0.0.1（既定）に割り当てられているか、ファイアウォールか VPN がポートを塞いでいます。0.0.0.0 か tailscale の IP に割り当て、信頼できるネットワークに対してポートを開けてください。

同じ構成を Web ダッシュボードの側から見たものは Web Dashboard → Connecting Hermes Desktop to a remote backend にあります。環境変数の一覧は Environment Variables → Web Dashboard & Hermes Desktop にまとめてあります。

デスクトップアプリを拡張する

デスクトップアプリは拡張で組み立てられています。ペイン、ページ、サイドバーのナビゲーション、ステータスバーの 項目、パレットのコマンド、キーバインド、テーマは、すべて1つの SDK を通して登録されていて、 自分のものを足すこともできます。プラグインは $HERMES_HOME/desktop-plugins/<id>/plugin.js に置く単一の ESM ファイルです。アプリは数秒のうちにそれを読み込み、 保存のたびにホットリロードします。導入済みのプラグインは Capabilities → Plugins でその場で管理できます。

全体の説明は Desktop Plugin SDK を参照してください。（これは web dashboard のプラグインの仕組みとは別物です。）

デスクトップのプラグインはサンドボックスに入りません。アプリの中で、アプリ自身の 権限（ゲートウェイの RPC、ネイティブのブリッジ、他のプラグインの保存領域）を持って動きます。自分で書いたか、 目を通したファイルだけを読み込んでください。カタログから導入する場合の守りは カタログの信頼モデル（人の目によるレビューと SHA の固定）と import の許可リストであって、隔離ではありません。 register() が例外を投げたプラグインは巻き戻され、その行にエラーとともに Failed と表示されます。 ⌘K → Reload desktop plugins は、導入済みの plugin.js をすべて読み直します。 インストーラーがその場で置き換えたものも含みます。

Capabilities → Plugins は、Hermes を拡張するものすべてを扱う唯一の場所です。 プラグイン1つにつき1行で、スイッチの列が2つあります。

• プラグインはこのアプリを拡張することも、エージェントを拡張することも、その両方もあります。各行の

バッジがどちらかを示し、パッケージの中身（plugin.yaml ならエージェント側、plugin.js ならデスクトップ側）から判断されます。両方を持つプラグインは1つの 行で、2行に分かれることはありません。

• Desktop の列 — このアプリに読み込まれる側です。アプリ単位で効くので、

ウィンドウがどのプロファイル、どのゲートウェイ、どのリモートの端末を見ていても、 同じスイッチ、同じ値です。デスクトップのコードが読み込まれる場所はちょうど1つ、 ~/.hermes/desktop-plugins/ です。エージェントとデスクトップが一体になったパッケージのデスクトップ側は、 導入時にアプリがそこへ複製します（更新やアンインストールにも追随します）。だからプロファイルを切り替えても、 ペインが読み込まれたり外れたり範囲が変わったりすることはありません。切り替えはその場で効きます。

• Agent の列 — 選択したプロファイルのバックエンドに導入される側です

（エージェントのプラグイン: user、git、project、pip、 持ち運び可能な形での導入）。カタログの固定が動いたときは Update のチップが付きます。 プロファイルの選択がこの列の見出しにあるのは、それが効くのがこの列だけだからです。 プロファイルが1つしかなければ、選択そのものが出ません。 リポジトリに同梱された組み込み（プラットフォームのアダプター、プロバイダーのプラグイン）は 並びません。有効な状態で出荷され、それぞれの画面から設定します。 例外は、自分の画面を持たない同梱のライフサイクルのプラグイン （disk-cleanup、security-guidance）で、他のエージェントのプラグインと同じように 切り替えられるようここに出ます。

• プラグインが持っていない側にはダッシュ（—）が出ます。デスクトップ側があるのに、エージェント側が

選択したプロファイルに入っていない場合は Install here が出て、 パッケージの出どころ（カタログの項目か git のリモート）から、そのプロファイルにだけ導入するダイアログを 埋めてくれます。Accent Picker のような任意の追加機能は、プラグインカタログから導入します。

• アンインストール — 選択したプロファイルの plugins/ フォルダの下に導入された

プラグイン（user または git での導入）には、名前の横にゴミ箱のボタンが付きます。 確認を求めたうえで、そのプロファイルからプラグインのファイルと導入の メタデータを削除します。hermes plugins remove <name> とまったく同じ操作で、 一体型パッケージのデスクトップ側について、アプリ単位の複製も片づけます。 プラグインのコードを外すにはゲートウェイを再起動してください。 リポジトリ同梱と pip（エントリーポイント）で入れたプラグインにゴミ箱のボタンはありません。 前者は削除できず、後者は Python のパッケージと一緒に消えます。 単体のデスクトップのプラグイン（エージェントのパッケージを持たず、 ~/.hermes/desktop-plugins/ に置いただけのフォルダ）にも同じゴミ箱の ボタンが付きます。確認するとこの端末上のそのフォルダが消え、プラグインは すぐ外れます。ゲートウェイは関係ありません。

その下には見つけるための入口があります。現行の Plugin Catalog の選択画面は、レビュー済みの項目を固定されたコミットで、選択したプロファイルへ導入します。 Install from Git は、それ以外のリポジトリを同じ「レビューしてから導入する」ダイアログで受け付けます。 任意の Pin to commit の欄に 40 文字のコミット SHA を1つ指定すると、そのコミットちょうどを導入します （プライベートなリポジトリも含みます）。固定したプラグインには一覧で pinned @ <sha8> のバッジが付きます。古い Settings → Plugins のリンクは ここへ転送されます。

困ったときは

アプリを再起動せずにつなぎ直す

接続が Connected のままなのに Desktop のチャットやボットが応答しなくなったら、そのボットやプロファイル、あるいはゲートウェイを選び、ステータスバーのゲートウェイのメニューを開いて Reconnect gateway を押してください。つなぎ直しは、開いている・つなごうとしている・切れている、どの状態の経路でも使えます。Desktop を再起動することも、他の経路のソケットをわざわざ閉じることもなく、いま使っている経路をつなぎ直します。選んだソケット上で処理中のリクエストは中断されることがあります。これは明示的な復旧の操作であって、バックエンドやモデルの再起動ではありません。

hermes update のあとアプリが消えた

以前の更新が apps/desktop/release/ を残さずにチェックアウトを置き換えていると、起動できるパッケージ済みのアプリが残りません。HERMES_HOME/desktop-build-stamp.json（Desktop のビルドが成功したときにだけ書かれます）が残っていれば、次の hermes update がアプリの不在に気づいて作り直します。手で作り直すなら hermes desktop --build-only --force-build です。Windows では、ZIP へのフォールバックもビルド済みのアプリ・そのレンダラーのバンドル・Electron の node_modules を入れ替えをまたいで保ちます。

ローカルのバックエンドがバックグラウンドで止まった

ローカルの Hermes のバックエンドのプロセスが、準備が整ったあとで終了した場合、Desktop は自分でそれを起動し直し、Hermes stopped working in the background の知らせを出します。代わりが立ち上がればチャットもつなぎ直されます。HERMES_HOME/logs/desktop.log には終了コードとバックエンドの最後の出力（Hermes backend exited (1) に続く Recent backend output:）が記録されるので、アプリが自力で立ち直った場合でも、死んだ理由はログに残ります。起動し直すたびに数秒で死に続けるなら、原因はバックエンド自身です。その末尾のトレースバックを見てください。2分のうちにこうした再起動が3回続くと、Desktop は繰り返しをやめて keeps crashing の知らせを出します。原因を直したら、アプリを起動し直してください。

失敗したターンは、どの層で失敗したかを示します

ターンが失敗すると、チャットには汎用のエラートーストではなく、どの層が 失敗したかを示すエラーカードが描かれます。プロバイダーやモデル、カスタムエンドポイント、ストリーミングの接続、 認証、課金、ゲートウェイ、ローカルのランタイム、ディスクのいずれかです。 カードには、その失敗に合った復旧の操作が並びます。

• Retry — 失敗したターンをその場でやり直します（やり直しても

同じ失敗を必ず繰り返す場合、たとえばコンテンツポリシーによる拒否では出ません）。 レート上限や利用上限の応答が、上限の解ける時刻を示しているとき （Retry-After ヘッダーか resets_at のフィールド）は、カードが Retry の隣に Limit resets at HH:mm (in 1h 05m) と出すので、いつやり直せば通るかが分かります。 CLI/TUI もエラーの下に同じ行を出します。この案内自体は 参考情報ですが、カードには Retry when the limit resets (HH:mm) も並びます。押すと、アプリはその解ける時刻に一度だけそのターンをやり直します。 残り時間の表示と Cancel の操作が付きます。この予約は 開いているウィンドウの中にしかありません。セッションを移る、別のメッセージを送る、 アプリを閉じる、のいずれでも消え、放っておいて勝手にやり直されることはありません。

• Switch provider — プロバイダー・エンドポイント・認証・課金の失敗に対して、

コンポーザーのモデルメニューをその場で開き、このチャットをすぐ別の プロバイダーやモデルへ移せるようにします（Settings → Models が変えるのは新しいチャットの 既定だけです）。チャットの画面が出ていないときは Settings → Models へ落ちます。

• Open logs — ファイルマネージャーで HERMES_HOME/logs を開きます。リモートや

Cloud の接続では、このボタンは Open Desktop logs になります。ローカルの Desktop 側のログ（通信の証拠）を開くという意味で、失敗したターンの ゲートウェイやエージェントのログは向こうの端末にあるからです。

• Send diagnostics — 明示的な同意の確認のあと、伏せ字処理を済ませたデバッグ用の一式を Nous の内部の

保管先へ送ります（hermes debug share --nous と同じ仕組みです。秘密情報は常に伏せられ、送ったものは Nous のスタッフだけが見られ、14 日後に自動で消えます）。成功すると サポートのやり取りに貼れる非公開の閲覧リンクが得られ、GitHub Issues、Nous Portal Support、 Discord への近道も付きます。リモートや Cloud の 接続では、バックエンドが自分のエージェントやゲートウェイのログをまとめ、ローカルの Desktop のログも添えられるので、サポートは両側を見られます。

• Copy error details — 層・コード・プロバイダーとモデル・エラーメッセージをまとめた

短いプレーンテキストの要約をコピーします。バグ報告や Discord に貼れます。

層の判定は、エージェントの再試行の処理が使うのと同じエラー分類器から来るので、 メッセージの文面からの推測ではなく、実際の失敗の意味を映しています。 この記述子より前の古いバックエンドでも、汎用のタイトルと Retry / Open logs / Copy error details の 操作を備えたカードは描かれます。

起動時のログは HERMES_HOME/logs/desktop.log に落ちます（バックエンドの出力と、直近の Python のトレースバックも含みます）。アプリが起動の失敗を報告したら、まずここを見てください。CLI から流し見することもできます。

hermes logs gui -f

正規のソースのインストールでは、デスクトップはインストールの起動スクリプトを確かめて実行します。 インタプリタと依存関係の世代は PM が選びます。その起動スクリプトが動くなら、 ブートストラップの目印のファイルが無くても、インストールをやり直すことはありません。

Linux では、Chromium 自身のエラーは HERMES_HOME/logs/desktop-chromium.log に出ます。シェル自体が落ちた場合は、アプリの Crashpad/ ディレクトリ（Electron のユーザーデータのディレクトリの中、connection.json の隣）にミニダンプが残ります。ウィンドウが消え、ジャーナルに SIGTRAP が出ているなら、そのログの FATAL: の行が、どのチェックが発火したかを示します。バグ報告に添えてください。どこにもアップロードされません。

Python の依存関係が壊れた場合は、そのインストールの hermes pm repair を実行してください。 そのあとデスクトップを再起動します。当て推量の venv のパスや PM の記録を消さないでください。 アプリのファイルが壊れた場合は、 インストールの所有者を通して修復してください。

# Reset a stuck macOS microphone prompt
tccutil reset Microphone com.nousresearch.hermes

Windows: SSH クライアントが無い、または壊れている

Windows では、アプリは標準の OpenSSH クライアント（%SystemRoot%\System32\OpenSSH\ssh.exe）で SSH を実行します。このクライアントが入っていないときは、Git for Windows に同梱の usr\bin\ssh.exe を使い、それも無ければ PATH 上にある ssh を使います。標準のクライアントは入っているのに壊れている場合（たとえば Windows Update のあと、どの ssh.exe も終了コード 255 で終わる場合）は、やり直しをせず、そのクライアント名を示すエラーで起動が止まります。別のクライアントを使うには、config.yaml で指定してからアプリを再起動してください。

desktop:
  ssh_path: 'C:\Program Files\Git\usr\bin\ssh.exe'

バックスラッシュがそのまま残るように、値は一重引用符で囲むか、引用符なしで書いてください。キーは、上で紹介した起動用のキーと同じく desktop: の下にスペース2つ下げて置きます。macOS と Linux では何の効果もありません。

「The host key has CHANGED since you last connected」（SSH のリモート）

SSH のリモートを入れ直したりホスト鍵を入れ替えたりすると、SSH は安全側に倒れて 失敗し、Desktop はやり直しをせずにエラーの覆いを掛けたままにします（古い鍵を消さないかぎり、 やり直しても決して通らないからです）。その変化が想定どおりかを確かめ、 古い項目を消してから、覆いの上でやり直してください。

ssh-keygen -R <host>

項目を消したら Retry を押す（あるいは Settings → Gateway で接続を入れ直す）と、 掛かっていた覆いが外れ、次の起動で新しくつなぎに行きます。

「Build desktop app」が Electron のダウンロードで止まる

ビルドは Electron のランタイム（約 114 MB）を github.com/electron/electron/releases からダウンロードします。インストーラーが Build desktop app の段で止まり、出力に retrying attempt=… が繰り返し出ているなら、あなたのネットワーク（ファイアウォール、プロキシ、あるいは地域）で GitHub が塞がれているか絞られています。

ビルドは、自分からミラーに切り替えることも、失敗したダウンロードをやり直すこともしません。理由が何であれビルドが失敗すると、以前のアプリはそのまま残り（段階的に用意してから入れ替える方式です。更新を参照）、更新そのものが失敗します。hermes desktop --build-only --force-build（または次の hermes update）で、もう一度ビルドが走ります。キャッシュ済みの Electron の zip が壊れていたのが原因なら、ビルドし直す前に @electron/get のキャッシュ（Linux は ~/.cache/electron/、macOS は ~/Library/Caches/electron/、Windows は %LOCALAPPDATA%\electron\Cache）から消してください。@electron/get はすべてのダウンロードの SHASUM を検証しますが、そのチェックサムも同じホストから来ます。そのため、指定したミラーは、ダウンロードとチェックサムの両方について信用することになります。

ミラーを使うなら（社内のもの、または事実上の Electron のコミュニティミラーである npmmirror.com など）、導入の前に ELECTRON_MIRROR を設定するか、手でビルドし直してください。ビルドはそれを尊重し、設定した値を上書きすることはありません。

ELECTRON_MIRROR=https://npmmirror.com/mirrors/electron/ \
  bash -c 'cd "$HOME/.hermes/hermes-agent/apps/desktop" && CSC_IDENTITY_AUTO_DISCOVERY=false npm run pack'

ミラーが要るその他のネイティブのダウンロード（Windows での get-windows のビルド済みバイナリなど）は、npm のキーを $HERMES_HOME/npmrc（Windows なら %LOCALAPPDATA%\hermes\npmrc、それ以外なら ~/.hermes/npmrc）に置いてください。たとえば node_get_windows_binary_host_mirror=https://<mirror>/sindresorhus/get-windows/releases/download/ のように書きます。更新処理が起動する npm ci / npm run（デスクトップ、web、TUI のビルド）はすべて、このファイルがあれば NPM_CONFIG_USERCONFIG をそこへ向けるので、設定は hermes update をまたいで残ります。リポジトリ直下の .npmrc は git の管理下にあって更新のたびに自動で退避されますし、~/.npmrc は、デスクトップへの引き継ぎが GUI の環境を受け継ぐために見落とされることがあります。自分で設定した NPM_CONFIG_USERCONFIG が上書きされることはありません。

get-windows が無い、あるいは中途半端に入っている場合、ビルドはもう失敗しません。[stage-native-deps] get-windows not installed ... read_window_below will be unavailable in this build と表示して、read_window_below のツールを載せずに出荷します。パッケージのディレクトリはあるのに読み込めない場合（Hermes のウィンドウが動いたまま Windows のその場での更新が中断されたとき、導入のログに TAR_ENTRY_ERROR が出ます）、同じ警告がそのディレクトリの名前を示し、次の hermes desktop --force-build か更新が、npm の導入の前にそれを消してパッケージを展開し直します。その前に Hermes のウィンドウとゲートウェイをすべて閉じて、展開がまた中断されないようにしてください。ネイティブのバインディングや macOS のヘルパーが欠けたパッケージも同様に、ビルドを失敗させるのではなく、ウィンドウの列挙なしで出荷されます。

壊れたキャッシュの zip を手で消すには次のようにします。

rm -f "$HOME/Library/Caches/electron"/electron-*.zip   # macOS
rm -f "$HOME/.cache/electron"/electron-*.zip            # Linux

ソースからビルドする

アプリ自体に手を入れたいなら、リポジトリのルートで一度ワークスペースの依存関係を入れてから、apps/desktop で開発サーバーを動かします。

npm install          # from repo root — links apps/desktop, web, apps/shared
cd apps/desktop
npm run dev          # Vite renderer + Electron, which boots the Python backend

特定のチェックアウトにアプリを向けたり、実際の設定から切り離して動かしたりもできます。

HERMES_DESKTOP_HERMES_ROOT=/path/to/clone npm run dev
HERMES_HOME=$HOME/.hermes/cache/scratch/throwaway npm run dev
npm run dev:fake-boot   # exercise the startup overlay with deterministic delays

インストーラーを作るには次のようにします。

npm run dist:mac     # DMG + zip
npm run dist:win     # NSIS + MSI
npm run dist:linux   # AppImage + deb + rpm
npm run pack         # unpacked app under release/ (no installer)

macOS と Windows の署名・公証は、必要な資格情報が環境にあれば自動で走ります（macOS なら CSC_LINK / CSC_KEY_PASSWORD / APPLE_*、Windows なら WIN_CSC_*）。

任意で使える HUD の修飾キータップのヘルパーは、Electron のバンドルと一緒にビルドされ、ASAR の外に収められます。macOS では、これまでどおり Xcode のコマンドラインツールが前提です。Windows のビルドは OS の .NET Framework に同梱された C# のコンパイラーを使うので、Clang や開発者向けの SDK は要りません。Windows のパッケージングは、ヘルパーを黙って省くのではなく失敗します。Linux のビルドには C のコンパイラーと X11/XInput の開発用ヘッダー（Debian/Ubuntu なら libx11-dev と libxi-dev）が要ります。この任意の Linux の前提が無ければ、修飾キータップに対応しないままパッケージングは進みます。ビルドは対象の OS の上で行ってください。Linux では対象のアーキテクチャも一致させる必要があります。導入して使うだけの人に開発用のツールチェーンは要りません。設定の画面は、ヘルパーが無い場合と起動に失敗した場合と、対応していないデスクトップのセッションとを区別します。Windows のヘルパーが無い、あるいは失敗した場合に X11/Wayland の警告は出ません。

macOS の権限とローカルの再ビルド（TCC）

フォルダの確認をすべて1つの切り替えで黙らせる。 macOS は Hermes が フォルダに触れるたび、カテゴリごと（デスクトップ、次にダウンロード、次に書類…）に確認を出します。 フルディスクアクセスを一度与えればそのすべてを永続的にまかなえますし、 Hermes の署名の identity は安定しているので、更新をまたいでも残ります。

1. システム設定 → プライバシーとセキュリティ → フルディスクアクセス（あるいは

open "x-apple.systempreferences:com.apple.preference.security?Privacy_AllFiles" を実行）

1. 使っているターミナルのアプリ、Desktop を使うなら Hermes.app も有効にします。
2. 両方を完全に終了してから起動し直します。

hermes doctor は、いまのターミナルの文脈がその許可をすでに持っているかを報告し、 hermes setup は macOS で持っていないときにこの案内を出します。

macOS は許可（フルディスクアクセス、デスクトップ／ダウンロード／書類、 アクセシビリティ、オートメーション、マイク）を、パスではなくアプリの*コード署名の identity* に 結び付けて覚えます。ローカルでビルドしたアプリや自己更新したアプリには、識別子を固定した 安定した ad-hoc の署名が付くので、許可は更新をまたいで残ります。

一度きりの注意。識別子を固定する署名の修正（PR #73681）*より前*のビルドに与えた 許可は、古い cdhash を固定した条件を抱えています。macOS はそうした古い許可のトグルを オンのまま見せますが、保存された許可が作り直したバイナリと一致しないので、やはり 確認を出し直します。しかも今の確認には許可のボタンが無いため、 確認し直す方法が無いように見えます。そうなったら、古い許可を一度リセットして 与え直してください。

tccutil reset ScreenCapture com.nousresearch.hermes   # repeat per service

そのあとシステム設定で新しい項目をオンにして、Hermes を完全に終了してから 起動し直します。以降は許可が安定します。

いちばん強い保証、つまり証明書に裏打ちされた identity が欲しいなら（yabai や skhd の 利用者が頼っているのと同じ仕組みです）、自己署名のコード署名の証明書を 一度作って、Hermes にそれを使うよう伝えます。ひとつのコマンドがすべてを やってくれます（ログイン用のキーチェーンに証明書を作り、codesign に アクセスを許し、設定を書き、パッケージ済みのアプリに署名し直します）。

hermes desktop --setup-tcc-identity

手でやるなら次のとおりです。

1. キーチェーンアクセス → 証明書アシスタント → 証明書を作成…
2. 名前は Hermes Local Signing、identity の種類は *自己署名ルート*、

証明書の種類は コード署名。

1. キーチェーンアクセスで新しい証明書をダブルクリック → 信頼 → コード署名 を

*常に信頼* にします（読み込んだ自己署名の証明書は、コード署名で信頼するまで 有効な署名の identity になりません。そのあと security find-identity -v -p codesigning に並ぶはずです）。

1. hermes config set desktop.macos_signing_identity "Hermes Local Signing"

別の名前の証明書を作って使うには、コマンドに --identity <name> を付けます （既定は Hermes Local Signing）。このコマンドは何度実行しても同じで、 更新のあとに走らせ直せば、設定を指し直して作り直したアプリに署名し直します。

次の更新は、その証明書で作り直したアプリに署名し直すので、TCC の許可は すべて残ります。Apple Developer のアカウントは要りません。公証済みのリリースのビルドは 検出され、署名し直されることはありません。

一度きりの注意。署名の identity を変えること（この修正のあとの最初の更新も含みます）は アプリの identity を一度変えるので、macOS は最後にもう一度だけ確認を出します。 以降は許可が安定します。許可が固まってしまったら、 tccutil reset All com.nousresearch.hermes でリセットして与え直してください。

関連

• CLI Guide — ターミナルのインターフェース
• TUI — hermes --tui とダッシュボードのチャットタブが使う、現代的なターミナル UI
• Web Dashboard — チャットタブを埋め込んだ、ブラウザの管理画面
• Configuration — デスクトップアプリが読み書きする設定
• Windows (Native) — Windows 向けのネイティブな導入経路