CLIコマンド一覧

このページの Python の依存関係のコマンドは、 PM で準備したソースのチェックアウトで実行する前提です。 依存関係を変えたら、チェックアウトを有効化し直して Hermes を再起動してください。

このページでは、シェルから実行するターミナルコマンドについて説明します。

チャット内で使うスラッシュコマンドについては、スラッシュコマンド一覧を参照してください。

グローバルエントリポイント

hermes [global-options] <command> [subcommand/options]

グローバルオプション

hermes-agent（旧来の単発クエリ用ランナー）

インストールすると hermes-agent も入ります。クエリを 1 つ送って終了するだけの最小限のランナーで、hermes-agent --query "summarize README.md"（または hermes-agent "summarize README.md"）のように使います。hermes-agent --help はオプション（--model、--base-url、--max-turns、--enabled-toolsets、--disabled-toolsets、--list-tools、--save-trajectories など）を一覧表示し、hermes-agent --version はバージョンを表示します。どちらもエージェントは起動しません。クエリを付けずに実行すると、同じヘルプを表示して終了します。それ以外の用途には hermes を使ってください（スクリプトから単発で実行するなら hermes -z <prompt> です）。

トップレベルコマンド

hermes chat

hermes chat [options]

共通オプション:

例:

hermes
hermes chat -q "Summarize the latest PRs"          # seeds an interactive session
hermes chat --oneshot -q "Summarize the latest PRs"  # answer and exit
hermes chat --provider openrouter --model anthropic/claude-sonnet-4.6
hermes chat --toolsets web,terminal,skills
hermes chat --quiet -q "Return only JSON"
hermes chat -q "Inspect this repository" --format stream-json
hermes chat --worktree -q "Review this repo and open a PR"
hermes chat --ignore-user-config --ignore-rules -q "Repro without my personal setup"
hermes chat --safe-mode --model gpt-4.1 -q "Is this bug mine or Hermes'?"
hermes chat --safe-mode --provider custom --base-url http://127.0.0.1:8000/v1 --model local -q "Isolate against a local server"

--format stream-json — 構造化 JSONL 出力

プログラムが端末出力をスクレイピングせずに進捗を取得したいときは --format stream-json を使います。-q / --query（または --query-file）が必須で、暗黙に quiet な非対話 CLI モードになり、明示的な --tui 指定は拒否されます。stdout の各行は1つの JSON オブジェクトで、診断情報と session_id: 行は stderr に残ります。

hermes chat -q "Summarize this repository" --format stream-json

すべてのイベントは timestamp（Unix エポックミリ秒）を持ちます。

会話が始まると、その終端のレコードは常に result です — Ctrl-C で中断された場合の exit_code: 130 も含みます。このレコードを完了信号として扱ってください。プロセスの終了コードはその exit_code と一致します。

one-shot 実行の終了コード

chat が回答して終了する場合（-Q、chat --oneshot、または非 TTY の標準入出力でのクエリ）、プロセスの終了コードは quiet／非 quiet のどちらの経路でもターンの結果を表します: 0 はターンが完了、1 は失敗した・途中で止まった（partial）・イテレーション予算に達した・一度も実行されなかった（認証情報/エージェント初期化の失敗）、130 は中断されたことを示します。Kanban ディスパッチャが起動したワーカー（HERMES_KANBAN_TASK が設定されている）のターンが、プロバイダのレートリミット・過負荷・5xx・タイムアウト・課金/クォータの上限だけを理由に失敗した場合は 75（EX_TEMPFAIL）で終了し、ディスパッチャは失敗を数えずにタスクを再キューします。--format stream-json を使う場合、終端の result レコードも同じ exit_code を持ちます。

有限の chat 実行での委任

chat が回答して終了する場合、delegate_task は子タスクをバックグラウンドで動かすのではなく、その完了を待って 結果を同じターンで返します。詳細と制約は 委任: 有限の chat 実行を参照してください。

hermes -z <prompt> — スクリプト向け one-shot

プログラムからの呼び出し（シェルスクリプト、CI、cron、プロンプトをパイプで渡す親プロセス）向けに、hermes -z は最も純粋な one-shot エントリポイントです。1つのプロンプトを渡すと、最終的な応答テキストだけが返り、stdout・stderr にはそれ以外は何も出ません。 バナーもスピナーもツールプレビューも Session: 行もなく、エージェントの最終的な返答がプレーンテキストで返るだけです。

hermes -z "What's the capital of France?"
# → Paris.

# Parent scripts can cleanly capture the response:
answer=$(hermes -z "summarize this" < /path/to/file.txt)

実行ごとの上書き（~/.hermes/config.yaml への変更なし）:

hermes -z "…" --provider openrouter --model openai/gpt-5.5
# or:
HERMES_INFERENCE_MODEL=anthropic/claude-sonnet-4.6 hermes -z "…"

同じエージェント、同じツール、同じスキル — 対話的・装飾的なレイヤーだけを取り除きます。トランスクリプトにツールの出力も残したい場合は、代わりに hermes chat --oneshot -q を使ってください。-z は明確に「最終的な回答だけが欲しい」ためのものです。

終了コード: 0 はターン完了。2 は失敗または途中で止まった場合（partial、イテレーション予算、completed: false）— 説明が出力されていた場合も含みます。130 は中断。1 は完了したターンがテキストを一切生成しなかった場合。2 は実行開始前の使用エラー（不正なフラグ）でも使われます。これらのコードは、上の chat -q/-Q（失敗/partial/予算超過で 1、テキストなしの完了で 0 を返す）とは意図的に異なります: -z は「何も回答しなかった」ために 1 を予約しています。実行の判定は終了コード（または --usage-file のフラグ）で行い、stdout が空でないかどうかでは判定しないでください。

--usage-file — パイプライン向け JSON 使用状況レポート

hermes -z "…" --usage-file /path/report.json は、実行後に機械可読な使用状況レポートを書き出します: estimated_cost_usd、input_tokens / output_tokens / cache_read_tokens / cache_write_tokens / reasoning_tokens / total_tokens、api_calls、model、provider、session_id、service_tier、completed / failed / partial / interrupted の各フラグ、そして turn_exit_reason（completed が false になった理由、例: max_iterations_reached(3/3)）。これらのトップレベルのカウンタはメインのエージェントループだけを対象にしています。同じ実行内で行われる補助的な LLM 呼び出し（タイトル生成、vision、コンテキスト圧縮、web_extract、バックグラウンドレビューなど）は auxiliary の下に別途レポートされます — 同じ合計値とタスク別の by_task マップです — そして total_including_auxiliary（estimated_cost_usd、total_tokens、api_calls）が課金対象の総計です。このレポートは実行が失敗した場合でも書き出されるため、バッチパイプラインは常に費用を追跡できます。-z/--oneshot の外では何も影響せず、使用状況の書き出しが壊れても実行自体の結果を隠すことはありません。

hermes -z "summarize this repo" --usage-file ~/.hermes/cache/scratch/usage.json
jq .total_including_auxiliary.estimated_cost_usd ~/.hermes/cache/scratch/usage.json
jq .auxiliary.by_task ~/.hermes/cache/scratch/usage.json      # what did title generation / vision cost?

hermes model

プロバイダ + モデルの対話型セレクタです。新しいプロバイダの追加、API キーのセットアップ、OAuth フローの実行を行うコマンドです。 実行中の Hermes チャットセッションの中ではなく、ターミナルから実行してください。

hermes model

次のような場合に使います:

• 新しいプロバイダを追加する（OpenRouter、Anthropic、Copilot、DeepSeek、カスタムなど）
• OAuth 対応のプロバイダにログインする（Anthropic、Copilot、Codex、Nous Portal）
• API キーを入力・更新する
• プロバイダ固有のモデル一覧から選ぶ
• カスタム/自前ホストのエンドポイントを設定する
• 新しい既定値を設定に保存する

/model スラッシュコマンド（セッション中）

セッションを離れずに、設定済みのモデル間を切り替えます:

/model                              # Show current model and available options
/model claude-sonnet-4              # Switch model (auto-detects provider)
/model zai:glm-5                    # Switch provider and model
/model custom:qwen-2.5              # Use model on your custom endpoint
/model custom                       # Auto-detect model from custom endpoint
/model custom:local:qwen-2.5        # Use a named custom provider
/model openrouter:anthropic/claude-sonnet-4  # Switch back to cloud

既定では、/model の変更は現在のセッションだけに適用されます。--global を付けると、変更を config.yaml に永続化できます（あるいは model.persist_switch_by_default: true を設定すると、すべての切り替えが永続化されます）:

/model claude-sonnet-4 --global     # Switch and save as new default

--global での切り替え時には、プロバイダとベース URL の変更もモデルとともに config.yaml に永続化されます。カスタムエンドポイントから切り替える際は、古くなったベース URL が消去され、他のプロバイダに漏れ込むのを防ぎます。

hermes gateway

hermes gateway <subcommand>

サブコマンド:

オプション:

--external-supervisor は再起動ポリシーの契約です: チャット内での再起動、hermes gateway restart、サービス再起動を伴うアップデートは、いずれもステータス 75 で終了します（その後 CLI は自前でフォアグラウンドのゲートウェイを実行する代わりに、スーパーバイザーが発行する新しい PID を待ちます）。そのため、ラッパー側のスーパーバイザーはその非ゼロ終了の後にゲートウェイを再起動する必要があります。systemd では Restart=on-failure または Restart=always を使い、RestartPreventExitStatus に 75 を含めないでください。launchd では、失敗した終了後に再起動するよう KeepAlive を設定してください。このポリシーがないと、要求された再起動でゲートウェイが停止したままになります。

hermes gateway enroll は --token、--connector-url、--gateway-id、--wake-url を受け付けます。登録トークンをコネクタと交換し、結果の GATEWAY_RELAY_ID、GATEWAY_RELAY_SECRET、GATEWAY_RELAY_DELIVERY_KEY、（あれば）GATEWAY_RELAY_URL、（--wake-url を指定した場合は）GATEWAY_RELAY_WAKE_URL の値を、アクティブなプロファイルの .env に書き込みます。

手元の実行環境の検出と起動

hermes gateway ensure [--json] [--timeout 60] は、使用中のプロファイルのセッション実行環境を探すか起動し、 JSON オブジェクトを 1 つ出力します（state、reason_code、そして認証付きの検出で互換性のある準備完了が確認できたときだけ endpoint が入ります。チケットや認証情報は決して含まれません）。 すでに動いている、または起動中の持ち主がいれば、置き換えずにそれを待ちます。サービスを登録することもありません。 終了コード 0 は準備完了を意味します。それ以外のコードは拒否か期限切れであって、代わりのものを起動してよいという意味ではありません。 サービスの身元確認、unsafe_control_permissions の背景にあるホームディレクトリの権限方針、すべての終了コードは ゲートウェイの内部構造: hermes gateway ensureにあります。

hermes lsp

hermes lsp <subcommand>

Language Server Protocol 連携を管理します。LSP は実際の言語サーバー（pyright、gopls、rust-analyzer など）をバックグラウンドで実行し、その診断結果を write_file と patch が使う post-write チェックに渡します。git ワークスペースの検出で制御されており — cwd または編集対象のファイルが git worktree 内にあるときだけ LSP が動作します。

サブコマンド:

詳しいガイド、サポート言語、設定については LSP — セマンティック診断 を参照してください。

hermes setup

hermes setup [model|tts|terminal|gateway|tools|agent] [--non-interactive] [--reset] [--quick] [--reconfigure] [--portal]

最も簡単な方法: hermes setup --portal — Nous Portal に OAuth でログインし、Tool Gateway を一度で有効にします。

初回実行: 初回セットアップウィザードが起動します。

再訪ユーザー（設定済み）: そのままフルの再設定ウィザードに入ります — すべてのプロンプトで現在の値がデフォルトとして表示され、Enter で維持、または新しい値を入力できます。メニューはありません。

ウィザード全体ではなく1つの区分だけを行う:

オプション:

hermes portal

hermes portal [status|open|tools]

Nous Portal の認証、Tool Gateway のルーティングを確認し、サブスクリプションページへの到達手段を提供します。サブコマンドなしで呼び出すと status が実行されます。

ゲートウェイ自体の設定については Tool Gateway を、one-shot のセットアップ手順については上記の hermes setup --portal を参照してください。

hermes whatsapp

hermes whatsapp

WhatsApp のペアリング/セットアップフローを実行します。モード選択や QR コードのペアリングも含みます。

hermes slack

hermes slack manifest              # print manifest to stdout
hermes slack manifest --write      # write to ~/.hermes/slack-manifest.json
hermes slack manifest --long-description-file AGENTS.md --write
hermes slack manifest --slashes-only  # just the features.slash_commands array

COMMAND_REGISTRY（/btw、/stop、/model など）に登録されているすべてのゲートウェイコマンドを、Discord や Telegram と同等の一級の Slack スラッシュコマンドとして登録する Slack app manifest を生成します。出力を、https://api.slack.com/apps の自分のアプリ設定 → Features → App Manifest → Edit に貼り付け、Save してください。スコープやスラッシュコマンドが変わった場合、Slack は再インストールを促します。

新しいコマンドを反映するには、hermes update の後に hermes slack manifest --write を再実行してください。

hermes send

hermes send --to <target> "message text"
hermes send --to <target> --file <path>
echo "message" | hermes send --to <target>
hermes send --list [platform]

エージェントやゲートウェイのループを一切起動せずに、設定済みのメッセージングプラットフォームへ one-shot メッセージを送信します。ゲートウェイが設定済みの認証情報（~/.hermes/.env + ~/.hermes/config.yaml）を再利用するので、運用スクリプト・cron ジョブ・CI フック・監視デーモンは、各プラットフォームの REST クライアントを再実装せずにステータス通知を投稿できます。

bot トークン型のプラットフォーム（Telegram、Discord、Slack、Signal、SMS、WhatsApp-CloudAPI）ではゲートウェイの起動は不要です — hermes send はプラットフォームの REST エンドポイントに直接話しかけます。永続的なアダプタを必要とするプラグイン型のプラットフォームは、稼働中のゲートウェイが必要です。

位置引数の message も --file も指定されない場合、hermes send は TTY でないときに stdin から読み込みます。終了コード: 成功時 0、配信/バックエンドの失敗時 1、使用エラー時 2。

画像などのメディアを送る

--file は*テキスト*本文専用です。画像、ドキュメント、動画、音声ファイルをプラットフォームのネイティブな添付として届けるには、メッセージ本文に MEDIA:<local_path> ディレクティブを含めます:

hermes send --to telegram "MEDIA:~/.hermes/cache/scratch/screenshot.png"
hermes send --to telegram "Build chart for today MEDIA:~/.hermes/cache/scratch/chart.png"   # with caption
hermes send --to discord:#ops "MEDIA:~/.hermes/cache/scratch/report.pdf"

既定では、画像ファイルは写真として送信されます（Telegram などのプラットフォームはこれを再圧縮します）。メッセージに [[as_document]] を追加すると、非圧縮のファイル添付として届けられます:

hermes send --to telegram "[[as_document]] MEDIA:~/.hermes/cache/scratch/screenshot.png"

例:

hermes send --to telegram "deploy finished"
echo "RAM 92%" | hermes send --to telegram:-1001234567890
hermes send --to discord:#ops --file ~/.hermes/cache/scratch/report.md
hermes send --to slack:#eng --subject "[CI]" --file build.log
hermes send --list                  # all platforms
hermes send --list telegram         # filter by platform

hermes peer

hermes peer add <name> --url http://host:port --key <API_SERVER_KEY>
hermes peer list
hermes peer dm <peer>[/<agent>] "message"
hermes peer run <peer>[/<agent>] --idempotency-key <key> "message"
hermes peer status <peer>[/<agent>] <run_id>
hermes peer stop <peer>[/<agent>] <run_id>
hermes peer remove <name>

マシンを超えた bot-to-bot の DM です。他の Hermes ゲートウェイ（api_server プラットフォームを実行しているマシン）を*peer* として登録し、そのエージェントにメッセージを送ります: hermes peer dm は、peer の API サーバー経由でリモートエージェントの正規の Bot Chat セッションを解決し、そこで1回のエージェントターンを実行して、その返答を stdout に出力します — ローカルの hermes -p <bot> chat --in ~ -c "Bot Chat" … という bot メッセージングコマンドの、マシンを超えた双子です。

<peer> だけを指定すると peer ゲートウェイのメインエージェントを対象にします。 <peer>/<agent> は、多重化された peer 上の名前付きプロファイル（その /p/<profile>/ ミラー経由でルーティングされる）を対象にします。

peer が1つ以上登録されると、すべての正規 Bot Chat に教え込まれる Bot Mode メッセージングプロトコル（agent.bot_mode_protocol）は、peer 一覧と hermes peer dm パターンを自動的に含むようになり、エージェントは SOUL の編集なしにマシンを超えたチームメイトを発見できます。Bot Mode を参照してください。

終了コード: 成功時 0、配信/peer の失敗時 1、使用エラー時 2。

hermes secrets

hermes secrets bitwarden <subcommand>
hermes secrets bw <subcommand>          # short alias

~/.hermes/.env に保存する代わりに、プロセス起動時に外部のシークレットマネージャから API キーを取得します。現状サポートしているのはBitwarden Secrets Managerです。詳しいガイド: Bitwarden integration。

bitwarden（別名 bw）のサブコマンド:

hermes migrate

hermes migrate <type>

廃止されたモデルや非推奨の設定への参照を診断し、（オプションで）現在アクティブな config.yaml を書き換えます。書き換えの前には、元の config.yaml のタイムスタンプ付きバックアップが取られます（--no-backup でスキップ）。

移行サブコマンド共通のフラグ:

> hermes claw migrate（OpenClaw の設定を Hermes へ one-shot でインポートする機能）と混同しないでください — hermes migrate はトップレベルの設定書き換えコマンドです。

hermes codex-runtime

hermes codex-runtime migrate [--dry-run] [--json]

チャットセッションを介さずに /codex-runtime codex_app_server がトリガーする ~/.codex/config.toml の移行を実行します: Hermes の mcp_servers（加えてインストール済みの codex プラグインと default_permissions の既定値）が、選択したプロファイル（hermes -p <name> codex-runtime migrate）向けの管理ブロックに投影されます。ブロック外のユーザーのテキストはそのまま保持され、Hermes のサーバーと同じ名前を持つユーザー所有の [mcp_servers.<name>] は保持され、その名前に対する Hermes の投影はスキップされます（preserved_user_servers として報告されます）。結果は、アトミックな書き込みの前に TOML として検証され、レポートにエラーが含まれる場合は終了コードが 1 になります。

hermes proxy

hermes proxy <subcommand>

OAuth 認証済みのアップストリームプロバイダ（Nous Portal、xAI など）へリクエストを転送するローカルの OpenAI 互換 HTTP サーバーを実行します。外部アプリはどのベアラートークンでもこのプロキシに向けられ、プロキシが送信時に実際の OAuth 認証情報を付与します。詳しいガイドは Subscription Proxy を参照してください。

hermes security

hermes security <subcommand>

OSV.dev に対するオンデマンドの脆弱性スキャンです。Hermes の venv（インストール済みの PyPI ディストリビューション）、~/.hermes/plugins/ 配下のプラグインが宣言する Python の依存関係、config.yaml にピン留めされた npx/uvx の MCP サーバーが対象です。グローバルにインストールされたパッケージやエディタ/ブラウザの拡張機能はスキャンしません。

audit のフラグ:

hermes login / hermes logout *(非推奨)*

hermes auth

同一プロバイダのキーローテーション用の認証情報プールを管理します。詳細は Credential Pools を参照してください。

hermes auth                                              # Interactive wizard
hermes auth list                                         # Show all pools
hermes auth list openrouter                              # Show specific provider
hermes auth add openrouter --api-key sk-or-v1-xxx        # Add API key
hermes auth add openrouter --type oauth                  # Browser login (OpenRouter PKCE) mints a key for you
hermes auth add anthropic --type oauth                   # Add OAuth credential
hermes auth add openai-codex --type oauth --priority 0   # Add an account and try it first
hermes auth add openai-codex --browser                   # Codex: browser auth-code + PKCE on localhost:1455 instead of device code
hermes auth remove openrouter 2                          # Remove by index
hermes auth priority openrouter backup-key 0             # Move a credential to the front of fill_first order
hermes auth reset openrouter                             # Clear cooldowns
hermes auth reset openrouter 2                           # Clear the cooldown on one credential
hermes auth refresh openai-codex work                    # Refresh one OAuth credential and clear its cooldown
hermes auth status anthropic                             # Show auth status for a provider
hermes auth logout anthropic                             # Log out and clear stored auth state

サブコマンド: add, list, remove, reset, priority, refresh, status, logout。Spotify へのログインは、カタログにある spotify プラグインの hermes spotify login に移りました。サブコマンドなしで呼び出すと、対話型の管理ウィザードが起動します。

hermes usage

/usage スラッシュコマンドのアカウント上限ブロック — Codex の5時間/週次ウィンドウ、プランとバンクされたリセット、Anthropic OAuth のウィンドウ、OpenRouter のクレジット — をセッションを開始せずに取得できるので、シェルスクリプトや cron ジョブから読み取れます。

hermes usage                          # configured model provider, human-readable block
hermes usage --provider openai-codex  # a specific provider
hermes usage --json                   # one JSON document on stdout

認証情報は、稼働中のエージェントがないセッションでの /usage と全く同じ方法で解決されます（認証ストア、次に認証情報プール）。このコマンドは chat が使わないような認証情報を新たに追加・更新することはありません。終了コード: 成功時 0；プロバイダに認証情報が設定されていない、プロバイダに usage エンドポイントがない、または取得に失敗した場合は、stderr に1行だけ出して 1（stdout は空のままです）。

--json のスキーマ（キーは安定しています。新しいキーが追加される場合があります）:

{
  "provider": "openai-codex",
  "source": "usage_api",
  "title": "Account limits",
  "plan": "Plus",
  "fetched_at": "2026-09-19T07:58:55+00:00",
  "windows": [
    {"label": "Session", "used_percent": 37.0, "resets_at": "2026-09-19T21:00:00+00:00", "detail": null},
    {"label": "Weekly", "used_percent": 12.5, "resets_at": "2026-09-25T09:00:00+00:00", "detail": null}
  ],
  "details": ["You have 1 reset banked - use /usage reset to activate"],
  "unavailable_reason": null
}

used_percent は、プロバイダがそのウィンドウを報告しなかった場合 null になります。resets_at は ISO-8601 UTC または null です（一部のウィンドウは代わりに自由記述の detail を持ちます）。plan は不明な場合 null になります。

hermes status

hermes status [--full] [--deep]

既定では、1画面に収まる要約を表示します。内容は、モデル、使用中のプロバイダ、認証情報が登録された すべてのプロバイダ（/model の選択画面に出るものと同じ一覧）、gateway の状態、gateway が起動する メッセージングプラットフォーム、予約ジョブです。キーの値は表示しません。

hermes cron

hermes cron <list|create|edit|pause|resume|run|remove|status|runs|incidents|doctor|tick>

cron のトリガーは、cron.provider の設定キーで差し替えられます。空（既定）の場合は組み込みのプロセス内ティッカーが使われます。chronos（scale-to-zero なホスト型ゲートウェイ向けの NAS 管理プロバイダ）に設定する場合は、cron.chronos.* のキー（portal_url, callback_url, expected_audience, nas_jwks_url）で構成します。または plugins/cron/<name>/ や $HERMES_HOME/plugins/<name>/ の下にカスタムプロバイダを名付けます。未知の、または利用できないプロバイダは組み込みのものにフォールバックするため、cron がトリガーを持たない状態にはなりません。詳細は cron internals のドキュメントを参照してください。

hermes kanban

hermes kanban [--board <slug>] <action> [options]

マルチプロファイル・マルチプロジェクトのコラボレーションボードです。1つのインストールで複数のボードをホストできます（プロジェクト、リポジトリ、ドメインごとに1つ）。各ボードは、専用の SQLite DB とディスパッチャのスコープを持つ独立したキューです。新規インストールは default という1つのボードから始まり、そのDBは後方互換のために ~/.hermes/kanban.db になります。追加のボードは ~/.hermes/kanban/boards/<slug>/kanban.db に置かれます。ゲートウェイに組み込まれたディスパッチャは、tick ごとにすべてのボードを掃きます。

グローバルフラグ（以下すべてのアクションに適用）:

これは人間 / スクリプト向けのインターフェースです。 ディスパッチャが起動するエージェントワーカーは、hermes kanban をシェル実行するのではなく、専用の kanban_* ツールセット（kanban_show、kanban_complete、kanban_request_review、kanban_request_changes、kanban_block、kanban_create、kanban_link、kanban_comment、kanban_heartbeat；オーケストレータ用プロファイルはさらに kanban_list と kanban_unblock も持ちます）を通じてボードを操作します。ワーカーは環境変数 HERMES_KANBAN_BOARD が固定されているため、物理的に他のボードを見ることができません。

例:

# Create a second board and put a task on it without switching away.
hermes kanban boards create atm10-server --name "ATM10 Server" --icon 🎮
hermes kanban --board atm10-server create "Restart server" --assignee ops

# Switch the active board for subsequent calls.
hermes kanban boards switch atm10-server
hermes kanban list                  # shows atm10-server tasks

# Archive a board (recoverable) or hard-delete it.
hermes kanban boards rm atm10-server
hermes kanban boards rm atm10-server --delete

ボードの解決順序（優先度の高い順）: --board <slug> フラグ → HERMES_KANBAN_BOARD 環境変数 → ~/.hermes/kanban/current ファイル → default。

すべてのアクションは、boards サブコマンドや --board フラグを含め、同じ引数の形でゲートウェイのスラッシュコマンド（/kanban …）としても利用できます。

Cline Kanban / Paperclip / NanoClaw / Gemini Enterprise との比較、8つのコラボレーションパターン、4つのユーザーストーリー、並行性の正しさの証明を含む全体のデザインについては、Kanban user guide を参照してください。

hermes egress

リモートのターミナルサンドボックス向けの、送信方向の認証情報注入ファイアウォールです。iron-proxy デーモンをラップしています — これは TLS を中間で解釈し、ネットワークの境界で不透明なプロキシトークンを実際のアップストリーム API 認証情報に差し替えるプロキシで、サンドボックスは本物のキーを一切保持しません。既定では無効です。セットアップとアーキテクチャの詳細は Egress proxy のページ全体を参照してください。

hermes egress install                  # download the pinned iron-proxy binary
hermes egress install --force          # check and repair the managed copy

hermes egress setup                    # interactive wizard: CA, mappings, config
hermes egress setup --tunnel-port N    # override the tunnel listener port (default 9090)
hermes egress setup --from-bitwarden   # use Bitwarden Secrets Manager as credential source
hermes egress setup --no-bitwarden     # explicitly switch back to env-based credentials
hermes egress setup --rotate-tokens    # mint fresh proxy tokens (default preserves existing)

hermes egress start                    # spawn the managed proxy daemon
hermes egress stop                     # SIGTERM (then SIGKILL after 5s grace)
hermes egress restart                  # stop (if running) then start — needed for secret changes
hermes egress reload                   # hot-reload the ruleset in-place (no restart, no dropped
                                       #   connections) via the loopback management API

hermes egress status                   # binary + config + pid + listening + mappings
hermes egress status --show-tokens     # print proxy tokens in full (default: redacted)

hermes egress disable                  # flip proxy.enabled = false (does not stop a running proxy)
hermes egress config                   # print the path to proxy.yaml for inspection

一般的なフロー

# First-time setup
export OPENROUTER_API_KEY=…
hermes egress setup && hermes egress start
hermes config set terminal.backend docker   # if not already

# Switching credential source after the fact
hermes egress setup --from-bitwarden       # env → bitwarden
hermes egress setup --no-bitwarden         # bitwarden → env
# (just `setup` without either flag preserves the existing mode)

# Rotating all tokens (e.g. after a suspected token leak)
hermes egress setup --rotate-tokens    # setup offers to restart the running daemon for you
# (running sandboxes still hold old tokens; restart them too)

# Adding a new upstream
# Edit ~/.hermes/config.yaml proxy.extra_allowed_hosts: [api.example.com]
hermes egress setup
hermes egress restart                  # one-command apply (stop + start)

診断のショートカット

hermes egress status                     # current state in one view
cat ~/.hermes/proxy/proxy.yaml           # the rendered iron-proxy config
tail -20 ~/.hermes/proxy/iron-proxy.log  # daemon-level diagnostics
tail -f ~/.hermes/proxy/iron-proxy.log | jq  # daemon + per-request log (line-delimited JSON; v0.39 combines both streams)

よくある失敗パターンとその復旧方法は Egress proxy → Troubleshooting にまとめています。

hermes project

hermes project <create|list|show|add-folder|remove-folder|rename|set-primary|use|archive|restore|bind-board>

プロジェクトは、複数のフォルダ/リポジトリをまとめられる、人間が名付けたワークスペースです。デスクトップのセッショングルーピングの基点となり、kanban ボードに紐付いている場合は、タスクに決定的な worktree + ブランチ規則を与えます。状態はプロファイル単位です。

hermes webhook

hermes webhook <subscribe|list|remove|test>

イベント駆動でのエージェント起動用に、動的な webhook サブスクリプションを管理します。設定で webhook プラットフォームが有効になっている必要があります — 未設定の場合はセットアップ手順が表示されます。

hermes webhook subscribe

hermes webhook subscribe <name> [options]

サブスクリプションは ~/.hermes/webhook_subscriptions.json に永続化され、ゲートウェイを再起動せずに webhook アダプタによってホットリロードされます。既存の名前で subscribe を再実行すると、--secret / --route-profile を渡さない限り、そのシークレットとプロファイル紐付けが維持されます。

hermes doctor

hermes doctor [--fix]

終了ステータス: レポートに未解決の問題がない場合は 0、1つ以上残っている場合（--fix が修復できなかった問題を含む）は 1 です。そのため、ヘルスゲートや CI のステップは hermes doctor をチェックとして信頼できます。

API Connectivity の節には IPv6 route チェックが含まれます: 既知のデュアルスタックホストへ、短い（2秒の）IPv6 TCP 接続を1回開きます。ルートが広告されているのにタイムアウトするだけの場合（ブラックホール化した IPv6 プレフィックス）、対処法として network.force_ipv4: true を名指しした警告として報告されます。IPv6 ルートが全くないのは健全な状態として OK と報告されます。すでに force_ipv4 が設定されている場合、このチェック自体がスキップされます。

カスタムエンドポイントの設定チェック（どちらも警告のみで、--fix はこれらを書き換えません）:

• custom_providers が YAML のリストでない場合（例: 不正な config set が残した文字列）は、そのキーと実際の型を名指ししたエラーとして報告されます — 再びリストに戻るまで、ランタイムはすべてのカスタムエンドポイントを無視します。
• 対応する providers: の項目（同じエンドポイント URL を持つもの）がない、古い形式の custom_providers リストの項目は、取るべき対処と共に報告されます: そのような項目は、モデルピッカーや Custom Endpoints ページが両方から読み取る廃止済みのリストストアからまだ配信されていて、リストを providers: へ移す one-shot の v12 マイグレーションは二度と実行されません。他のすべての画面が編集する providers: マップからではなく、廃止済みのリストストアから配信されているままです。

Config Structure も、1つのクォート済み文字列として保存されているリスト/マッピングの設定（plugins.enabled: '["a","b"]'、model_catalog.excluded_providers: '["openai-api"]' — 古いバージョンの config set が書いていた形）を検出します: すべての読み取り側はそのような文字列を無視するため、プラグインは静かにマウントされないままになり、除外設定も一切適用されません。この検出結果は、そのキー名と、実際のリストを保存する hermes config set <key> '<literal>' コマンドを名指しします。同じ警告は起動時のバナーにも表示されます。--fix はこのファイルを書き換えません。

hermes dump

hermes dump [--show-keys]

自分の Hermes セットアップ全体の、コンパクトなプレーンテキストの概要を出力します。Discord、GitHub の Issue、Telegram でサポートを求める際にコピペできるように設計されています — ANSI カラーも特殊な書式もなく、データだけです。

含まれる内容

出力例

--- hermes dump ---
version:          0.8.0 (2026.4.8) [af4abd2f]
os:               Linux 6.14.0-37-generic x86_64
python:           3.11.14
openai_sdk:       2.24.0
profile:          default
hermes_home:      ~/.hermes
model:            anthropic/claude-opus-4.6
provider:         openrouter
terminal:         local

api_keys:
  openrouter           set
  openai               not set
  anthropic            set
  nous                 not set
  firecrawl            set
  ...

features:
  toolsets:           all
  mcp_servers:        0
  memory_provider:    built-in
  gateway:            running (systemd)
  platforms:          telegram, discord
  cron_jobs:          3 active / 5 total
  skills:             42

config_overrides:
  agent.max_turns: 250
  compression.threshold: 0.85
  display.streaming: True
--- end dump ---

いつ使うか

• GitHub でバグを報告するとき — Issue にダンプを貼る
• Discord でヘルプを求めるとき — コードブロックで共有する
• 自分の設定を他の人のものと比較するとき
• 何かがうまく動かないときの簡単な健全性チェック

hermes debug

hermes debug share [options]

デバッグレポート（システム情報 + 直近のログ）をペーストサービスにアップロードし、共有可能な URL を取得します。素早いサポート依頼に便利です — 対応する側が問題を診断するために必要なものをすべて含みます。

レポートには、システム情報（OS、Python のバージョン、Hermes のバージョン）、直近のエージェント・ゲートウェイ・GUI/ダッシュボード・デスクトップのログ（ファイルごとに 512 KB 上限）、あれば更新ログと Desktop からの更新の引き継ぎログ、redaction 済みの API キーの状態が含まれます。既定ではアップロードは redaction されるため、シークレットは含まれません。これはログだけでなく、システムの情報（fallback_providers の項目やその URL に含まれる認証情報といった設定値を含みます）にも、ゲートウェイの /debug レポートにも当てはまります。

既定のアップロードは、公開のペーストサービス（paste.rs、dpaste.com の順）を試します。--nous は同じデバッグバンドルを非公開の Nous 診断ストレージにアップロードします。返される viewer リンクは Nous チーム用で、14日後に自動削除されます。

例

hermes debug share              # Upload debug report, print URL
hermes debug share --lines 500  # Include more log lines
hermes debug share --expire 30  # Keep paste for 30 days
hermes debug share --nous       # Upload a private diagnostics bundle for Nous support
hermes debug share --local      # Print report to terminal (no upload)

hermes backup

hermes backup [options]

Hermes の設定、スキル、セッション、データの zip アーカイブを作成します。バックアップは hermes-agent のコードベース自体を除外し、以前のバックアップの成果物（backups/、state-snapshots/）を入れ子にしません — それぞれが既に state.db 自身のコピーを持っています。

バックアップは SQLite の backup() API を使って安全にコピーするため、Hermes が実行中でも正しく動作します（WAL モードでも安全です）。

終了ステータス: 選択したすべてのファイルがアーカイブに入った場合のみ 0。一部のファイルを追加できなかった場合（Backup incomplete: …）、残りが復元できるよう zip はそのまま保持されますが、コマンドは 1 で終了します — cron や systemd タイマーが不完全なアーカイブを成功として報告することはなく、--keep による整理もスキップされ、既存の完全なアーカイブは残ります。2 は、別のバックアップが既に実行中だったことを意味します。

zip から除外されるもの:

• *.db-wal、*.db-shm、*.db-journal — SQLite の WAL / 共有メモリ / journal のサイドカーです。*.db ファイル自体は sqlite3.backup() によって一貫したスナップショットを取得済みなので、稼働中のサイドカーを一緒に出荷すると、リストア時に半分だけコミットされた状態を見せてしまいます。
• checkpoints/ — セッション単位の履歴キャッシュです。ハッシュキー付きでセッションごとに再生成されるため、他のインストールにそのまま移植する意味もありません。
• ~/.hermes のルート（および各 profiles/<name>/ のルート）にある models/、runtimes/、node/ — 再生成可能なランタイムダウンロードで、数十 GB になることもあります。同名でも深い階層のディレクトリ（スキルの models/ など）は保持されます。
• ブラウザプロファイル: browser-profile/（実プロファイルのスナップショット — コピーされた Cookies / Login Data）、browser-profiles/（生きている CDP プロファイル、深さを問わず）、そして browser_profiles/（Browser Use CLI バックエンドの Chromium ユーザーデータディレクトリで、独自の Login Data / Cookies を持つ。~/.hermes のルートおよび各 profiles/<name>/ のルートにあるもの）。これらは決してアーカイブに入れてはならない認証情報ストアで、いずれも次回起動時に再生成されます。
• 同じルートにある cache/ の再生成可能な項目 — モデル/プラグインのカタログ、スタンプ、ブラウザプロファイル、ツール出力の溢れ分です。永続的なアーティファクトは残ります: cache/images、cache/audio、cache/videos、cache/documents、cache/screenshots（あなたに配信された、またはあなたから受け取ったメディア）、そして cache/citations（根拠となる引用の記録）。スキル内などより深い階層の cache/ はそのまま丸ごと保持されます。
• Unix ソケット、デバイス、シンボリックリンク — zip はこれらを保持できません。除外前は、迷い込んだ gateway.sock があるとフルバックアップが必ず Backup incomplete を報告していました。
• hermes-agent のコード自体（これはユーザーデータのバックアップであり、リポジトリのスナップショットではありません）。

例

hermes backup                           # Full backup to ~/hermes-backup-*.zip
hermes backup -o ~/backups/hermes.zip   # Full backup to specific path
hermes backup --quick                   # Quick state-only snapshot
hermes backup --quick --label "pre-upgrade"  # Quick snapshot with label

hermes checkpoints

hermes checkpoints [COMMAND]

~/.hermes/checkpoints/ にあるシャドウ git ストア — セッション内の /rollback コマンドを支えるストレージ層 — を確認・管理します。いつでも安全に実行でき、エージェントが動作中である必要はありません。

オプション

例

hermes checkpoints                                  # status overview
hermes checkpoints prune --retention-days 3         # aggressive cleanup
hermes checkpoints prune --max-size-mb 200          # tighten size cap once
hermes checkpoints clear-legacy -f                  # drop v1 archive dirs
hermes checkpoints clear -f                         # wipe everything

アーキテクチャ全体とセッション内コマンドについては Checkpoints and /rollback を参照してください。

hermes import

hermes import <zipfile> [options]

以前作成した Hermes のバックアップを、自分の Hermes ホームディレクトリに復元します。アーカイブ内のすべてのファイルが既存のファイルを上書きします。--force は、対象に既に Hermes のインストールがあるときに出る確認プロンプトだけをスキップします。

終了ステータス: アーカイブが壊れている場合は 1 です。何かを書き込む前に、すべてのメンバーを一度展開して CRC を確かめます。1 つでも失敗すると Error: backup archive is damaged (N member(s) …) と問題のメンバーを表示し、Hermes のホームには一切手を付けずに止まります。アーカイブ内のファイルを 1 つでも復元できなかった場合も 1 です（Warnings (N files skipped) の下に一覧が出て、Import incomplete: … とまとめて表示されます）。書き込めたファイルはそのまま残りますが、スクリプトやダッシュボードが途中までの復元を成功として扱うことはありません。インポートが意図してこの端末のものを残すランタイムファイル（gateway.pid、gateway_state.json、…）と、下で説明する古いバックアップのセッションに関する警告は、終了ステータスに影響しません。

SQLite データベース

.db のメンバー（state.db、kanban.db、response_store.db など）は、通常のファイルのようなリネームでは配信されません。リネームは、ゲートウェイやダッシュボード、WebUI のプロセスがまだ古いファイルを開いたままの状態で、そのファイルの inode を差し替えてしまいます。そのプロセスは、インポート前の古いページを読み続け、他の誰にも見えないセッションを書き続けることになり、そのセッションは全員が次に開くデータベースから単純に欠落します — 何もログに残りません。代わりに、インポートされたページは、/snapshot restore が行うのと同じ方法で、既存のデータベースファイルに直接書き込まれ、開いているすべての接続がインポートされたデータへ収束します。

生きているデータベースを安全に差し替えられない場合（ページのコピーが失敗し、*かつ*他のプロセスがまだそのファイルを開いている場合）、インポートはそのデータベースに触れず、Warnings (N files skipped) の下に一覧します。ファイルを保持しているプロセスを停止し、再実行してください。

新しい作業を上書きする古いバックアップのインポートは今も許可されていますが、無音ではなくなりました。インポートされた state.db が、置き換える前より少ないメッセージ数しか持っていない場合、概要にその旨が報告されます:

  ⚠ Session data replaced by older backup contents:
    state.db: 12 session(s) / 8912 message(s) -> 3 / 24
    Anything recorded after the backup was taken is not in it.
    Recover from a newer backup or snapshot: hermes snapshot list

例

hermes import ~/hermes-backup-20260423.zip           # Prompts before overwriting existing config
hermes import ~/hermes-backup-20260423.zip --force   # Overwrite without prompting

hermes logs

hermes logs [log_name] [options]

Hermes のログファイルを表示・追跡・フィルタします。すべてのログは ~/.hermes/logs/（デフォルト以外のプロファイルでは <profile>/logs/）に保存されます。

ログファイル

オプション

トレースバックの各行や、複数行にわたるメッセージの続きのように、自分の時刻を持たない行は、その上にある時刻付きの行といっしょに表示されたり隠されたりします。

例

# View the last 50 lines of agent.log (default)
hermes logs

# Follow agent.log in real time
hermes logs -f

# View the last 100 lines of gateway.log
hermes logs gateway -n 100

# Show only warnings and errors from the last hour
hermes logs --level WARNING --since 1h

# Filter by a specific session
hermes logs --session abc123

# Follow errors.log, starting from 30 minutes ago
hermes logs errors --since 30m -f

# List all log files with their sizes
hermes logs list

フィルタリング

フィルタは組み合わせられます。複数のフィルタが有効な場合、ログの行が表示されるにはすべてのフィルタを通過する必要があります:

# WARNING+ lines from the last 2 hours containing session "tg-12345"
hermes logs --level WARNING --since 2h --session tg-12345

パースできるタイムスタンプを持たない行は、--since が有効な間は含まれます（複数行にわたるログエントリの継続行かもしれないためです）。検出可能なレベルを持たない行は、--level が有効な間は含まれます。

ログローテーション

Hermes は Python の RotatingFileHandler を使います。古いログは自動的にローテーションされます — agent.log.1、agent.log.2 などを探してください。hermes logs list サブコマンドは、ローテーションされたものを含むすべてのログファイルを表示します。

hermes prompt-size

hermes prompt-size [--platform <name>] [--json]

新しいセッションの固定プロンプト予算 — どんな会話内容よりも*前*に、すべての API 呼び出しごとに送られるもの — を報告します。ダウンストリームのアダプタやプロキシが、モデルのコンテキストウィンドウより厳しいプロンプト予算を持つ場合、または、どのブロック（スキル索引、メモリ、プロファイル）が支配的かを知りたい場合に便利です。

エージェントが使うのと同じシステムプロンプトを組み立て、それを内訳に分解します:

• System prompt total — 組み立てられたプロンプト全体（identity、guidance、スキル索引、コンテキストファイル、メモリ、プロファイル、タイムスタンプ）。
• Skills index — <available_skills> ブロックです。多くのスキルをインストールしていると、これが最大のブロックになることがよくあります。
• Memory と user profile — あなたの MEMORY.md / USER.md のスナップショットです。
• Prompt tiers — stable / context / volatile。Hermes がキャッシュに優しい形でプロンプトを層に分けている方法と一致します。
• Tool schemas — 有効なすべてのツールの JSON です（固定ペイロードの残り半分です）。

完全にオフラインで動作します — API 呼び出しはなく、認証情報が一切設定されていなくても動作します。

# Human-readable breakdown for the CLI platform (default)
hermes prompt-size

# Simulate a messaging platform's prompt (different platform hint)
hermes prompt-size --platform telegram

# Machine-readable output for scripts
hermes prompt-size --json

hermes config

hermes config <subcommand>

サブコマンド:

config set model.provider <provider> は model: ブロックを1つの経路にまとめます: 前のプロバイダから残った model.base_url / model.api_mode は、それが他のプロバイダのエンドポイントである場合、削除されます（かつ一覧に表示されます） — そうしないと、新しいプロバイダのキーが古いエンドポイントに送信され、間違ったプロバイダを名指しした認証情報エラーで失敗してしまいます。新しいプロバイダ自身のエンドポイントである URL、名前付きの custom_providers の項目のエンドポイント、custom/ローカルの別名の下にある URL はそのまま残ります。見覚えのないホスト（プロキシ、LAN サーバー）は、それでも適用され続けるという警告付きで残ります。

キー名の中のドット

hermes config set/get/unset は . をネストの区切り文字として使いますが、実際のキー名には、モデル ID（grok-4.6、glm-5.3-flash）、Matrix のルーム ID（!room:example.org）、バージョン付きのプロバイダ名など、リテラルなドットを含むものが多くあります。次の2つのルールで、これらをアドレス可能にしています:

• 既存のキーはそのまま動きます。 既存のマッピングをたどるとき、ドット区切りの残りの部分と一致する既存のリテラルキーは、分割よりも優先されます。hermes config set providers.p.models.grok-4.6.supports_vision true は、実際の grok-4.6 の項目を更新します（get/unset も同じ方法で解決します）。
• 新しいドット付きキーの作成にはエスケープが必要です。 リテラルなドットはバックスラッシュでエスケープします: hermes config set 'providers.p.models.grok-4\.7.context_length' 128000 はリテラルな grok-4.7 キーを作成します（シェルがバックスラッシュを保持するよう、キーをクォートしてください）。

エスケープしない書き込みが、既存のドット付きの兄弟キーを隠してしまうネストされたマッピングを作ろうとする場合（例: 既存の grok-4.6 の隣に grok-4 を作る場合）、コマンドはエラーで失敗し、ランタイムが決して読まない幻の項目を無音で書き込むことはありません。

hermes pairing

hermes pairing <list|approve|revoke|clear-pending>

hermes skills

hermes skills <subcommand>

サブコマンド:

よくある例:

hermes skills browse
hermes skills browse --source official
hermes skills search react --source skills-sh
hermes skills search https://mintlify.com/docs --source well-known
hermes skills inspect official/security/1password
hermes skills inspect skills-sh/vercel-labs/json-render/json-render-react
hermes skills install official/migration/openclaw-migration
hermes skills install skills-sh/anthropics/skills/pdf --force
hermes skills install https://sharethis.chat/SKILL.md                     # Direct URL (+ referenced support files)
hermes skills install https://example.com/SKILL.md --name my-skill        # Override name when frontmatter has none
hermes skills check
hermes skills update
hermes skills config
hermes skills reset google-workspace
hermes skills reset google-workspace --restore --yes
hermes skills opt-out                  # stop future bundled-skill seeding (nothing deleted)
hermes skills opt-out --remove --yes   # also delete UNMODIFIED bundled skills
hermes skills opt-in --sync            # undo: remove marker and re-seed now

補足:

• --force は、サードパーティ/コミュニティのスキルに対する、危険ではないポリシーブロックを上書きできます。
• --force は dangerous のスキャン判定を上書きしません。
• --source skills-sh は公開の skills.sh ディレクトリを検索します。
• --source well-known は、/.well-known/skills/index.json を公開しているサイトを Hermes に指定させます。
• --source browse-sh は、200以上のサイト固有ブラウザ自動化スキルを集めた browse.sh のカタログを検索します。識別子は browse-sh/airbnb.com/search-listings-ddgioa のような形になります。
• http(s)://…/*.md の URL を渡すと、SKILL.md に加えて、references/、templates/、scripts/、assets/、examples/ の下で明示的に参照されているファイルもインストールされます。frontmatter に name: がなく、URL のスラッグが有効な識別子でない場合、対話的なターミナルでは名前の入力を求められます。非対話的な画面（TUI 内の /skills install、ゲートウェイのプラットフォーム）では代わりに --name <x> が必須です。

hermes bundles

hermes bundles <subcommand>

スキルバンドルは、複数のスキルを1つの /<bundle-name> スラッシュコマンドにまとめます。バンドルを呼び出すと、参照されているすべてのスキルが1つの結合されたユーザーメッセージとしてロードされます。保存先: ~/.hermes/skill-bundles/<slug>.yaml。YAML のスキーマと挙動については Skill Bundles を参照してください。

サブコマンド:

例:

hermes bundles create backend-dev \
  --skill github-code-review \
  --skill test-driven-development \
  --skill github-pr-workflow \
  -d "Backend feature work"

hermes bundles list
hermes bundles show backend-dev
hermes bundles delete backend-dev

チャットセッション内では、/bundles がインストール済みのバンドルを一覧し、/<bundle-name> が1つをロードします。

hermes curator

hermes curator <subcommand>

curator は、エージェントが作成したスキルを定期的にレビューし、古くなったものを整理し、重複を統合し、使われなくなったスキルをアーカイブするバックグラウンドの補助モデルタスクです。バンドルスキルと hub からインストールしたスキルは決して触れられません。アーカイブは復元可能で、自動削除は起きません。

新規インストールでは、最初の予約された実行は1回分の interval_hours（既定7日）だけ後ろにずれます — hermes update の後の最初の tick で、ゲートウェイが即座に整備を始めることはありません。この前に確認したい場合は hermes curator run --dry-run を使ってください。

挙動と設定については Curator を参照してください。

hermes moa

名前付きの Mixture of Agents プリセットを設定します。プリセットは、すべてのモデルピッカーの Mixture of Agents プロバイダの下に選択可能なモデルとして表示されます。/moa <prompt> は1つのプロンプトを既定のプリセットで実行します。

hermes moa list
hermes moa configure [name]
hermes moa delete <name>

hermes moa configure は、参照モデルとアグリゲータそれぞれについて、Hermes のプロバイダ→モデルピッカーを再利用します。プリセットは実行モードの設定であり、プライマリのモデルやプロバイダではありません。

hermes fallback

hermes fallback <subcommand>

フォールバックプロバイダのチェーンを管理します。フォールバックプロバイダは、プライマリモデルがレートリミット、過負荷、接続エラーで失敗したときに順に試されます。

Fallback Providers を参照してください。

hermes hooks

hermes hooks <subcommand>

~/.hermes/config.yaml で宣言されたシェルスクリプトフックを確認し、合成ペイロードに対してテストし、~/.hermes/shell-hooks-allowlist.json にある初回使用時の同意アローリストを管理します。

イベントのシグネチャとペイロードの形については Hooks を参照してください。

hermes memory

hermes memory <subcommand>

外部メモリプロバイダのプラグインをセットアップ・管理します。同梱のプロバイダ: retaindb、byterover。honcho、hindsight、supermemory、mem0、openviking、holographic（プラグインカタログ）は hermes plugins install <name> のあとで使えます（memory.provider にすでに指定されているプロバイダなら、hermes update がこのインストールを自動で行います）。同時にアクティブにできる外部プロバイダは1つだけです。組み込みメモリ（MEMORY.md/USER.md）は常にアクティブです。

サブコマンド:

hermes acp

hermes acp

エディタ連携用に、Hermes を ACP（Agent Client Protocol）の stdio サーバーとして起動します。

関連するエントリポイント:

hermes-acp
python -m acp_adapter

先にサポートをインストールしてください:

cd ~/.hermes/hermes-agent && python -c "import pm; pm.sync_venv(['acp'], explicit=True)"

ACP Editor Integration と ACP Internals を参照してください。

hermes mcp

hermes mcp <subcommand>

MCP（Model Context Protocol）サーバーの設定を管理し、Hermes を MCP サーバーとして実行します。

MCP Config Reference、Use MCP with Hermes、MCP Server Mode を参照してください。

hermes connectors

hermes connectors <subcommand>

ホスト型コネクタのアカウント（Nous のツールゲートウェイ経由で使う Gmail などのアプリ）を管理します。Nous Portal へのサインインが必要です。1つのアプリに名前付きのアカウントを複数持てます。Multiple connector accounts を参照してください。

名前の変更には、それに対応した Nous Portal のバージョンが必要です。対応するまでは「This Nous Portal cannot rename connector accounts yet.」と表示されます。

hermes plugins

hermes plugins [subcommand]

一般的なプラグイン、メモリプロバイダ、コンテキストエンジンを1か所で統合管理します。サブコマンドなしで hermes plugins を実行すると、2つの区分を持つ複合的な対話画面が開きます:

• General Plugins — インストール済みプラグインを有効/無効にするマルチセレクトのチェックボックスです
• Provider Plugins — Memory Provider と Context Engine の単一選択の設定です。区分の上で ENTER を押すとラジオピッカーが開きます。

プロバイダプラグインの選択は config.yaml に保存されます:

• memory.provider — アクティブなメモリプロバイダ（空 = 組み込みのみ）
• context.engine — アクティブなコンテキストエンジン（"compressor" = 組み込みの既定値）

一般プラグインの無効化リストは config.yaml の plugins.disabled に保存されます。 Git によるインストールも、プロファイルローカルの plugins/.install-metadata.json サイドカーに、正規のソース、インストールされた正確なリビジョン、ピンの状態だけを記録します。プラグインの設定、環境変数の値、シークレット、機能の許可は含まれません。

Plugins と Build a Hermes Plugin を参照してください。

hermes tools

hermes tools [--summary]

--summary を指定しない場合、プラットフォームごとの対話的なツール設定 UI が起動します。

hermes computer-use

hermes computer-use <subcommand>

サブコマンド:

hermes computer-use install は、computer_use ツールセットが使う cua-driver バイナリをインストールする安定したエントリポイントです。hermes tools で初めて Computer Use を有効にしたときに実行されるのと同じ upstream のインストーラを実行するので、ツールトグルがそれをトリガーしなかった場合（例: 再訪ユーザーのセットアップ）に、インストールを再実行するために安全に使えます。

cua-driver が既に存在する場合、Hermes はそのバージョンとランタイムのマニフェストを確認します。0.20.0 以上と互換性のあるインストールはそのまま維持されます。古い、または不完全な標準インストールは、現行の upstream インストーラで修復されます。Hermes は HERMES_CUA_DRIVER_CMD で選ばれたカスタムバイナリを決して置き換えません。そのバイナリは直接更新するか、上書き設定を削除してください。修復が必要な場合、hermes computer-use status がそれを報告します。

組み込みの computer_use ツールセットが、推奨される Hermes の統合方法です。生の Cua MCP ツールを登録するのは、Cua の低レベルなツールの語彙が必要なときの代替手段です。cua-driver skills install は Hermes を検出し、Cua のスキルパックを Hermes のスキルディレクトリに自動的にリンクします。

権限モードとケーパビリティマニフェストの承認は、ランタイムの起動に属します。bounded モードでは、Hermes は Cua の正規の --capability-manifest と --approve-capability-manifest フラグを渡します。すべての MCP トランスポートは、そのランタイム内に専用のライフサイクルセッションを持ちます。公開されるセッション名は、カーソルとセッションの状態を表すラベルであり、ランタイムを所有したり共有したりするものではありません。

hermes update は、cua-driver が PATH 上にある場合、更新の最後に upstream のインストーラを自動的に再実行するため、ほとんどのユーザーは --upgrade を手動で呼ぶ必要はありません。次回の Hermes の更新を待たずに、upstream が出した修正を今すぐ使いたいときに使ってください。

hermes pets

hermes pets <list|install|select|show|off|scale|remove|doctor>

Petdex は、コーディングエージェント向けのアニメーションスプライトペットを集めた公開ギャラリーです。1つをインストールすると、Hermes は CLI、TUI、デスクトップアプリ全体で、エージェントの活動に反応するそのペットを表示します。

テキストによる説明から全く新しいペットを生成することもできます。/hatch スラッシュコマンドを使ってください。Pets を参照してください。

hermes sessions

hermes sessions <subcommand>

サブコマンド:

hermes insights

hermes insights [--days N] [--source platform]

hermes claw

hermes claw migrate [options]

OpenClaw のセットアップを Hermes に移行します。~/.openclaw（またはカスタムパス）から読み込み、~/.hermes に書き込みます。古いディレクトリ名（~/.clawdbot、~/.moltbot）や設定ファイル名（clawdbot.json、moltbot.json）も自動的に検出します。

何が移行されるか

移行は、persona、メモリ、スキル、モデルプロバイダ、メッセージングプラットフォーム、エージェントの動作、セッションポリシー、MCP サーバー、TTS など、30以上の区分をカバーします。項目は Hermes の相当物へ直接インポートされるか、手動レビュー用にアーカイブされます。

直接インポートされるもの: SOUL.md、MEMORY.md、USER.md、AGENTS.md、スキル（4つのソースディレクトリ）、既定モデル、カスタムプロバイダ、MCP サーバー、メッセージングプラットフォームのトークンとアローリスト（Telegram、Discord、Slack、WhatsApp、Signal、Matrix、Mattermost）、エージェントの既定値（推論エフォート、圧縮、人間らしい遅延、タイムゾーン、サンドボックス）、承認ルール、TTS の設定、ブラウザ設定、ツール設定、実行タイムアウト、コマンドのアローリスト、ゲートウェイの設定、3つのソースからの API キー。

手動レビュー用にアーカイブされるもの: cron ジョブ、プラグイン、フック/webhook、メモリバックエンド（QMD）、スキルレジストリの設定、UI/identity、ロギング、マルチエージェントのセットアップ、チャンネルの紐付け、IDENTITY.md、TOOLS.md、HEARTBEAT.md、BOOTSTRAP.md。

API キーの解決は、優先順に3つのソースを確認します: 設定値 → ~/.openclaw/.env → auth-profiles.json。すべてのトークンフィールドは、プレーンな文字列、環境変数テンプレート（${VAR}）、SecretRef オブジェクトのいずれにも対応します。

完全な設定キーの対応表、SecretRef の扱いの詳細、移行後のチェックリストについては full migration guide を参照してください。

例

# Preview what would be migrated
hermes claw migrate --dry-run

# Full migration (all compatible settings, no secrets)
hermes claw migrate --preset full

# Full migration including API keys
hermes claw migrate --preset full --migrate-secrets

# Migrate user data only (no secrets), overwrite conflicts
hermes claw migrate --preset user-data --overwrite

# Migrate from a custom OpenClaw path
hermes claw migrate --source /home/user/old-openclaw

hermes import-agent

hermes import-agent [claude-code|codex] [options]

Claude Code（~/.claude）または OpenAI Codex CLI（~/.codex）のセットアップを Hermes にインポートします。CLAUDE.md/AGENTS.md の指示をメモリの項目に、Bash(...) 権限の許可/拒否ルールを command_allowlist/approvals.deny に、MCP サーバーを config.yaml の mcp_servers に、スキルディレクトリを ~/.hermes/skills/ にマッピングします。常に適用前にプレビューを表示し、API キーと認証情報は一切インポートされません。

インポートが成功するたびに、そのソースが ~/.hermes/import-sync.json に登録されます。hermes import-agent --sync は、その後、ファイルが変更された登録済みのソースを再インポートします（インポート済みの Claude Code / Codex のセットアップを最新に保つ、cron に適した方法です）。マッピング表の全体については import guide を参照してください。

hermes serve

hermes serve [options]

Hermes のバックエンドサーバーを起動します — デスクトップアプリやリモートクライアントが接続する JSON-RPC/WebSocket ゲートウェイです。これは hermes dashboard が実行するのと同じサーバーですが、ヘッドレスです: ブラウザ UI を一切開きません。デスクトップアプリは自前で hermes serve バックエンドを起動します。リモートホストでヘッドレスなバックエンドが欲しいときは、このコマンドを直接使ってください。下の hermes dashboard と同じ --host / --port / --insecure / --skip-build / --stop / --status のオプションを受け付けます（ループバック以外へのバインドは同じ認証ゲートを起動します）。[web] エクストラが必要です。埋め込みの Chat ソケットは、POSIX ホストではさらに [pty] を必要とします。

ポートの競合: 要求されたポート（既定 9119）が別のプロセス（例: 2つ目の hermes serve やゲートウェイ）に既に取られている場合、このコマンドは機械可読なセンチネル行 BACKEND_PORT_IN_USE port=<port> を stdout に、想定される保持者を名指しした人間向けのヒントを出力し、一般的なエラーの代わりにコード 75（EX_TEMPFAIL）で終了します — スクリプトやデスクトップアプリが「ポートが使用中」と「バックエンドが壊れている」を区別できるようにするためです。--port 0 を渡すと、空いているエフェメラルポートにバインドします（起動に成功すると、HERMES_BACKEND_READY port=<port> で選ばれたポートを知らせます）。

hermes dashboard

hermes dashboard [options]

Web ダッシュボードを起動し、設定、API キー、セッションを管理します。ヘッドレスなバックエンドが必要な場合は hermes serve を使ってください。FastAPI、Uvicorn、プラットフォームの PTY ヘルパーは中核の依存関係に含まれます。web の extra は HTTP スタックの厳密なバージョン制約を加えるもので、標準の PM のセットアップでは all を通して選ばれます。依存関係が壊れた場合は hermes pm repair を実行してください。埋め込みの Chat タブには、Linux、macOS、WSL2 のような POSIX の PTY 環境が必要です。Web Dashboard を参照してください。

hermes dashboard register

このインストールを、あなたの Nous Portal アカウントにセルフホストのダッシュボードとして登録します。OAuth クライアントを作成し、HERMES_DASHBOARD_OAUTH_CLIENT_ID を ~/.hermes/.env に書き込み、ログインゲートを起動する方法を表示します。ログイン済み（hermes setup）である必要があります。

# Default — opens browser to http://127.0.0.1:9119
hermes dashboard

# Custom port, no browser
hermes dashboard --port 8080 --no-open

# From a profile alias — routes to the machine dashboard with the
# profile preselected in the sidebar switcher (attach if running)
worker dashboard

hermes profile

hermes profile <subcommand>

プロファイルを管理します — それぞれが独自の設定、セッション、スキル、ホームディレクトリを持つ、複数の独立した Hermes インスタンスです。

例:

hermes profile list
hermes profile create work --clone
hermes profile create work --clone --sync-imports   # also carry over the import-agent sync manifest
hermes profile use work
hermes profile alias work --name h-work
hermes profile export work -o work-backup.tar.gz
hermes profile import work-backup.tar.gz --name restored
hermes profile install github.com/user/my-distro --alias
hermes profile update work
hermes -p work chat -q "Hello from work profile"

hermes completion

hermes completion [bash|zsh|fish]

シェル補完スクリプトを stdout に出力します。Hermes のコマンド、サブコマンド、プロファイル名のタブ補完のために、その出力をシェルのプロファイルに読み込んでください。

例:

# Bash
hermes completion bash >> ~/.bashrc

# Zsh
hermes completion zsh >> ~/.zshrc

# Fish
hermes completion fish > ~/.config/fish/completions/hermes.fish

hermes pm

ピン留めしたツール、Python の依存関係の環境、そしてそれらの診断を管理します。 このコマンドは Hermes のアプリケーションそのものは更新しません。

hermes pm --help
hermes pm doctor
hermes pm status
hermes pm repair
hermes pm install
hermes pm install chromium

ソースから開発する場合は、セットアップのスクリプトを一度実行し、そのあと source ./activate、PowerShell なら . .\activate.ps1 で インストールした環境を有効化します。 deactivate で元のシェルの環境に戻せます。準備、日常のコマンド、依存関係の更新、テスト環境については、 開発者向けのワークフローを参照してください。

すべてのサブコマンド、ソース版とバンドル版の動きの違い、遅延インストールの方針、メンテナー向けのコマンドは、 パッケージ管理を参照してください。

hermes update

hermes update [--gateway] [--check] [--plan] [--no-backup] [--backup] [--yes]

受け入れ済みのソースのチェックアウトを更新し、PM を通して依存関係を用意します。 更新を適用せずに、設定されたソースの対象と比べるには --check を使います。 デスクトップのバンドル、Docker、Nix、Termux のパッケージは、それぞれ外部の更新の仕組みが引き続き担当します。 更新とアンインストール を参照してください。

hermes update は、このインストールの更新チャンネルに従います。公式リポジトリのソースチェックアウトでは既定が stable で、GitHub で公開された最新の vX.Y.Z リリースのコミットそのものに合わせます。フォークやミラーでは既定が main です。main のすべてのコミットを追いたい場合は hermes update --set-channel main を実行します。hermes update --set-channel stable で元に戻せます。main チャンネルでは、チェックアウトが別のブランチにある場合、pull の前に更新用ブランチへ切り替えることがあります。更新の自動 stash フローの外にブランチ上の作業を残しておきたい場合は、更新前にコミットしてください。

追加の挙動:

• ゲートウェイの再起動。 更新の成功後、Hermes は更新対象のホーム（そのルートと、配下のすべての profiles/<name>）で実行中のゲートウェイプロファイルをすべて自動的に再起動しようとし、新しいコードを反映させます。同じマシン上でも別の HERMES_HOME に属するゲートウェイや hermes-gateway* サービス（別のインストールや、hermes update を実行している一時的なホーム）は、出力に名前を示したうえで手を付けずに残します。更新を適用せずにゲートウェイだけ再起動したいときは hermes gateway restart を使ってください。
• 再起動フェーズの復旧。 新しく取得したツリーをインポート中に、プロセス内の再起動フェーズが中断された場合、監視下にあるゲートウェイプロファイルは、クリーンな Python プロセスを通じて再試行されます。systemd（systemctl --user is-active）によって独立に確認された再起動だけが verified として報告されます。単に終了コード 0 を返しただけの再起動は relaunch_attempted として記録され、再起動は未完了のまま残ります（gateway_restart のフォローアップになります。コード自体は入っているので、更新そのものは終了コード 0 で終わります）。手動のゲートウェイと serve/dashboard のランタイムは、再起動の権限なしに強制終了されることはありません。それらは理由付きでスキップとして記録され、正確な再起動コマンドと共に不完全な更新レポートに残ります。
• 更新レシート + フリートのバージョン確認。 各実行は、ルートの Hermes ホームにある ~/.hermes/logs/update_receipts/ に機械可読なレシートを書き込みます。固定したプロファイルから実行した場合も同じです（更新前のフリート計画、各ステップ、理由付きのスキップ、再起動の結果、フォローアップ。latest.json は最新のものを指し、更新の途中は running になります）。再起動フェーズの後、アップデータは各稼働中のゲートウェイの実行中コードを更新後のチェックアウトと照合し、プロファイルごとのバージョン行列を表示します。新しいコードが入っていれば、更新前のコードのままのゲートウェイがあっても更新は失敗しません。正確な再起動コマンドを添えた ⚠ の行を表示して終了コード 0 で終わり、gateway_restart のフォローアップを記録して、再起動を未完了のまま残します。CLI を起動するたびにそのことが警告され、次の hermes update で再試行されます。
• ローカルのソース変更。 git によるインストールでは、追跡中の汚れたファイルと未追跡のファイルは、ブランチのチェックアウトや pull の前に自動的にスタッシュされます（git stash push --include-untracked）。対話的なターミナルでの更新では、スタッシュを復元する前に確認を求めます。非対話的な更新では、既定でそれを復元します。管理されたインストールで、意図的なローカルのソース編集を成功した pull の後に破棄したい場合だけ updates.non_interactive_local_changes: discard を設定してください。スタッシュの復元が競合する、または pull が失敗した場合、手動での復旧のためにスタッシュはそのまま残されます。
• npm のロックファイルの変動。 スタッシュやブランチの切り替えの前に、Hermes は npm の install/build ステップが生成した、追跡中の package-lock.json の差分をベストエフォートでクリーンアップします。意図的なロックファイルの編集は、hermes update を実行する前にコミットするか手動でスタッシュしてください。
• ペアリングデータのスナップショット。 --backup が off でも、hermes update は git pull の前に ~/.hermes/pairing/ と Feishu のコメントルールの軽量なスナップショットを取ります。pull が編集中だったファイルを書き換えてしまった場合、hermes backup restore --state pre-update でロールバックできます。
• 古い hermes.service の警告。 Hermes が、リネーム前の hermes.service の systemd ユニット（現行の hermes-gateway.service ではなく）を検出した場合、フラップループの問題を避けられるよう、一度だけ移行のヒントを表示します。
• 終了コード。 成功時 0、pull/install/post-install のエラー時 1、git pull をブロックする予期しない作業ツリーの変更があった場合は 2。

メンテナンスコマンド

| hermes uninstall [--full] [--gui] [--data] [--dry-run] [--yes] | ソースからのインストールで Hermes が持つファイルを削除します。--gui はソースからビルドしたデスクトップの削除を選びます。--full はデータも削除します。--data は、パッケージが持つコードは消さずにユーザーのデータを削除します。封じられたインストールでは、アプリケーションの削除はそのパッケージの管理側が行います。--dry-run は削除の範囲を事前に表示し、--yes は確認を省きます。 |

関連

• スラッシュコマンド一覧
• CLI Interface
• Sessions
• Skills System
• Skins & Themes