Agent Dispatch

agent-dispatch

Claude Code のエージェントが、他のプロジェクトディレクトリのエージェントにタスクを委任できるようにする MCP サーバーです。

各エージェントは、それぞれのプロジェクトディレクトリで個別の claude -p セッションとして実行されます。そのプロジェクトの MCP サーバー、CLAUDE.md、ツールをそのまま引き継ぎます。呼び出し元のエージェントは結果だけを受け取ります。

関連するプロジェクトは グループ としてまとめられます。共有ブリーフとメンバーリストからなり、1 つのセッションでそれらをまたいだ作業を調整できます（例: コードリポジトリ + infra/Portainer ゲートウェイ + analytics ゲートウェイ）。

OAuth、API キー、Claude サブスクリプションの認証に対応しています。

AI エージェントの方へ: この README は、このツールを使用するための正式なドキュメントです。セットアップ: クイックスタート（各手順には決定的な検証方法があります）、最初の呼び出し: dispatch、ツールの選択: どのツールを使うか、障害時の対応: エラーからの復旧。このリポジトリの開発を行う場合は AGENTS.md を参照してください。

クイックスタート

前提条件: Claude Code CLI がインストールされ、認証済みである必要があります。まず確認します:

claude --version   # must print a version — if it fails, install Claude Code before continuing

次に:

pip install agent-dispatch   # or: pipx install agent-dispatch

# 1. Create config + register the MCP server with Claude Code (user scope)
agent-dispatch init

# 2. Register project directories as agents — REPLACE the example paths with
#    real directories on your machine; they must exist (~ is expanded, relative
#    paths are resolved). Descriptions are auto-generated from project files.
#    No second project handy? Use the zero-setup block below instead.
agent-dispatch add infra ~/projects/infra
agent-dispatch add backend ~/projects/backend

# 3. Smoke test — dispatches a real task to the agent added in step 2 and prints
#    the answer; exit 0 on success. Default task when none given:
#    "What project is this? Describe in one sentence."
agent-dispatch test infra

# 4. Verify the whole install — prints "All checks passed." and exits 0 on success
agent-dispatch doctor

手順 2〜3 のセットアップ不要の代替方法（2 つ目のプロジェクトは不要で、現在のディレクトリを登録します）:

agent-dispatch add self . && agent-dispatch test self "Say hello"

これで、すべての Claude Code セッションで dispatch ツールが使えるようになります。独立した確認方法: claude mcp list が agent-dispatch: で始まる行を出力する必要があります。Claude Code セッション内からは、最初の MCP 呼び出しは list_agents()、次に dispatch(...) です。

init で MCP サーバーの登録に失敗する場合（Registered MCP server ではなく警告が出力される場合は）、手動で登録します:

claude mcp add-json agent-dispatch "{\"type\":\"stdio\",\"command\":\"$(which agent-dispatch)\",\"args\":[\"serve\"]}" --scope user

test が権限エラーで失敗する場合（error_type: "permission"）、ツールへのアクセスを許可して再テストします:

agent-dispatch update infra --allowed-tools "Bash,Read,Grep"      # least privilege
# or, if the agent needs everything (see SECURITY.md for the trade-off):
agent-dispatch update infra --permission-mode bypassPermissions

いつ dispatch するか

dispatch すべき場合は、タスクが他のプロジェクトのツール、ファイル、コンテキストを必要とするときです:

• infra エージェントの Portainer MCP 経由でコンテナログを確認する
• db エージェントの postgres MCP 経由でデータベースにクエリする
• 別のリポジトリのコードを読んだりテストを実行したりする

dispatch すべきでない場合は、自分で実行できるときです。dispatch すると完全な Claude セッションが起動されます。

MCP ツールリファレンス

list_agents

設定済みのすべてのエージェントを一覧表示します。何が利用できるかを確認するには、まずこれを呼び出してください。

// Response (capability + permission fields shown only when populated)
[
  {
    "name": "infra",
    "directory": "/home/user/projects/infra",
    "description": "Infrastructure agent. MCP: portainer. Stack: Python, Docker",
    "healthy": true,
    "has_claude_md": true,
    "has_mcp_config": true,
    "mcp_servers": ["portainer", "postgres"],
    "stacks": ["Python", "Docker"],
    "dbs": ["Alembic"],
    "capabilities": ["docker_logs", "deploy_debug"],
    "risky_capabilities": ["restart_services"],
    "permission_mode": "bypassPermissions",
    "allowed_tools": ["Bash", "Read", "Grep"],
    "typical": {"median_seconds": 143.3, "p90_seconds": 178.3, "median_cost_usd": 0.2666}
  }
]

mcp_servers、stacks、dbs はエージェントのプロジェクトファイル（.mcp.json、Dockerfile、pyproject.toml、Cargo.toml、prisma/、alembic.ini など）から検出されるため、呼び出し元はプローブを dispatch しなくても適切なエージェントを選べます。

typical は宣言された値ではなく実測値です。これはこのエージェント自身の最近の dispatch から使用ジャーナルに基づいて算出され、数回実行した後にのみ表示されます。timeout_seconds の見積もりや、呼び出し前にそのコストを知るために使用してください。ジャーナルがオフの場合やエージェントの履歴が少なすぎる場合は表示されません。データがないほうが、2 回の実行から導き出された典型的な所要時間より優れています。

inspect_agent

低コストな詳細ルックアップ — claude セッションを起動せずにエージェントのファイルを読み取ります。完全な設定（タイムアウト、モデル、予算、権限モード、許可/禁止ツール）、検出された MCP/スタック/DB、さらに存在する場合は CLAUDE.md と README.md の短いプレビューを返します。

パラメーター	型	必須	説明
name	string	はい	list_agents で取得したエージェント名
preview_lines	int	いいえ	CLAUDE.md/README.md の最大行数（デフォルト 40、最大 200、0 で無効化）

dispatch_async/dispatch の前にこれを使用して、エージェントがタスクに必要なツールとコンテキストを持っていることを確認してください — プローブディスパッチよりもはるかに低コストです。

また、エージェントの instructions（その常設指示）と完全な typical ブロックも保持します — list_agents で省略されたものに加え、dispatches、failed、そして outcomes の内訳です:

"typical": {
  "dispatches": 24, "median_seconds": 143.3, "p90_seconds": 178.3,
  "median_cost_usd": 0.2666, "failed": 1, "outcomes": {"done": 21, "partial": 2}
}

グループ

グループは、関連するエージェントをプロジェクト横断のワーキングセットに束ねます — 通常はいくつかのコードリポジトリとケイパビリティゲートウェイ（Portainer MCP を持つ infra エージェント、ブラウザー + Yandex Metrica を持つ analytics エージェント）です。これにより、1 つのオーケストレーションセッションがコード、デプロイ、検証にまたがる作業を調整できます。

グループは記述的なレイヤーであり、実行エンジンではありません — ルーターもステートマシンも存在しません。メンバーのヒントを読んでメンバーを選び、通常のディスパッチツールで調整します。2 つのテキストフィールドは 2 つの対象読者を想定しています:

• description — オーケストレーター向け: グループをどのように調整するか（ステップの順序、何のために誰を呼ぶか）。list_groups/inspect_group によって表示され、メンバーのプロンプトには決して注入されません。
• shared_context — メンバー向けの事実（スタック名、カウンター ID、規約）で、どのメンバーが読んでも成り立ちます。group= を渡すと、メンバーの context の先頭に自動的に付加されます。

メンバーは名前でエージェントを参照します。メンバーシップは多対多です（共有ゲートウェイは複数のグループに属せます）。グループは agent-dispatch group CLI（add/list/inspect/update/remove）で管理するか、agents.yaml を編集して管理します。

list_groups() — すべてのグループを低コストで、サブプロセスなしで読み出します: description、メンバー数、そして各メンバーの use_for ヒント + ヘルス。エージェントが削除されたメンバーは、クラッシュする代わりに "unknown": true とフラグが立てられます。

inspect_group(name) — 1 つのグループの完全なブリーフ: description、完全な shared_context、そしてメンバーリスト。特定のメンバーを深く掘り下げるには、inspect_agent(member) を呼び出してください — inspect_group は意図的に低コストなメンバーシップの読み出しにとどまります。

グループの使用 — dispatch に group= を渡します（または dispatch_parallel で項目ごとに）。エージェントはメンバーでなければなりません。そのグループの shared_context は自動的に付随します:

# From the shop-web codebase, hand the deploy to the infra gateway.
# The "shop" group's facts (stack name, counter id) are auto-attached.
dispatch(
    agent="infra",
    task="Redeploy the shop-web container",
    caller="shop-web",
    goal="ship the checkout fix",
    group="shop",
)

group=""（デフォルト）は、通常のディスパッチとバイト単位で同一です — 共有の事実は context 文字列に折り込まれるため、結果キャッシュはグループを自動的に区別し、グループなしの呼び出しは影響を受けません。

dispatch

ワンショットのタスク委任。結果はキャッシュされます — TTL 内の同一リクエストは即座に返されます。

パラメータ	型	必須	説明
agent	string	yes	list_agents で取得したエージェント名
task	string	yes	実行する内容 — 具体的に指定してください。エージェントはあなたの会話のコンテキストを持っていません
context	string	no	追加のコンテキスト: エラーメッセージ、コードスニペット、スタックトレース
caller	string	no	あなたのプロジェクト／役割 — エージェントが誰からの依頼かを理解する助けになります
goal	string	no	より広い目的 — エージェントがより良いトレードオフを行えるようになります
response_format	string	no	単一の JSON 値を要求するには "json" を指定します。パースされた結果は parsed_result に入ります。空 = 自由形式のテキスト。
return_ref	bool	no	true の場合、完全な結果テキストの代わりに ref とサマリープレビューのみを返します。必要に応じて fetch_result(ref) で完全なテキストを読み込めます。
summary_chars	int	no	ref レスポンスに含める結果テキストの最大文字数（デフォルト 500）。
timeout_seconds	int	no	この呼び出し限りのタイムアウト上書き（0 = エージェントに設定されたタイムアウト。10～7200 にクランプされます）。長時間かかると分かっているタスクでも設定を編集する必要はありません。
group	string	no	グループ名（list_groups で取得）。エージェントはメンバーである必要があります。グループの shared_context（メンバー向けの事実）は自動的に context の先頭に追加されます。空 = 通常のディスパッチ。グループを参照してください。

# Call — recommended form (always include caller and goal)
dispatch(
    agent="infra",                # must exist in list_agents()
    task="Check container logs for errors related to the scheduler service",
    context="Error: TypeError at scheduler.py:42",
    caller="backend",             # your project/role
    goal="debug production crash" # the broader objective
)

// Response (success)
{
  "agent": "infra",
  "success": true,
  "result": "Found 3 errors in container logs: TypeError in scheduler.py:42...",
  "session_id": "sess-abc-123",
  "cost_usd": 0.02,
  "duration_ms": 5000,
  "num_turns": 2,
  "outcome": "done"
}

// Response (failure — error_type helps you handle programmatically)
{
  "agent": "infra",
  "success": false,
  "result": "",
  "error": "Tool_use is not allowed in this permission mode\n\nHint: ...",
  "error_type": "permission"
}

error_type の値: permission（ツール／アクションが拒否された）、timeout、recursion（ディスパッチの深さが上限を超えた）、not_found（ディレクトリまたは CLI が見つからない）、budget（claude CLI が max_budget_usd でセッションを停止した）、usage_limit（Claude のアカウントがレート／セッション制限に達した）、cli_error（その他の失敗）。permission、budget、usage-limit、timeout のエラーには、実行可能なヒントが含まれます。

再開可能なタイムアウト: 新規のディスパッチはすべてセッション UUID（--session-id）を事前に割り当てるため、タイムアウトしたディスパッチでも session_id が返されます — 部分的なトランスクリプトは kill 後も残ります。タイムアウトエラーには復旧方法が明記されています: dispatch_session(agent, "Continue where you left off", session_id=...) で再開する、より大きな timeout_seconds で再試行する、または dispatch_async を使用する。

拒否されたツールの可視性: 非対話モードでは、claude CLI はエージェントが使用を許可されていないツールを自動的に拒否します — その結果、エージェントは*「読み取り専用のクエリ 1 つにあなたの許可が必要です」*のような回答で「成功」してしまうことがよくあります。その場合、レスポンスには決定的なシグナルが含まれます: denied_tools（CLI の permission_denials からパース）と、結果が不完全である可能性およびアクセスを許可する方法を説明する hint です。success は true のままです — これはソフトなシグナルであり、失敗ではありません。

// Response (success, but a tool was blocked)
{
  "agent": "analysis",
  "success": true,
  "result": "Here is the offline mapping. To finish I'd need to run one read-only query...",
  "denied_tools": ["Bash"],
  "hint": "1 tool call(s) were denied by permissions: Bash. The result may be incomplete..."
}

構造化 JSON 出力: エージェントに単一の JSON 値を求めるには response_format="json" を渡します。ランナーは指示のフッター（「単一の有効な JSON 値で応答し、フェンスや説明文を含めないこと」）を追加し、成功時にはレスポンスをパースします — パースされた値は parsed_result に入ります。生のテキストは常に result にあります。パースに失敗した場合、parsed_result=None のままになりますが、ディスパッチは失敗しません（ソフトモード）。

// Response with response_format="json"
{
  "agent": "infra",
  "success": true,
  "result": "{\"errors\": 3, \"first_at\": \"14:02\"}",
  "parsed_result": {"errors": 3, "first_at": "14:02"}
}

常に caller と goal を渡してください — ディスパッチされたエージェントには構造化されたプロンプトが見えます:

## Goal
debug production crash

## Dispatched by
backend

## Context
Error: TypeError at scheduler.py:42

## Task
Check container logs for recent errors related to the scheduler service

ディスパッチプロトコルと outcome。 claude -p はそれ自体では別のエージェントから操作されていることを認識しません: 曖昧なタスクを与えられると、*「どのサービスを指しているのか明確にしていただけますか？」*のような言葉で平然と終了します — 何も答えていない課金対象の実行であり、その後プレーンなキャッシュが TTL の間ずっと同じものを返し続けることになります。そのため、すべてのディスパッチはエージェントのシステムプロンプトに短いディスパッチプロトコルも追加します（--append-system-prompt を使用し、タスクのテキストには決して混ぜません）:

• 非対話で実行されており、caller からディスパッチされていて、質問に答える人もアクションを承認する人もいない — 前提を明示して進め、2 つの解釈が異なる場合はより安全な読み方を選ぶこと。
• 拒否されたツールや存在しないものは、報告すべき事項であり、そこで止まるべき事項ではない — 可能な他のすべてを完了させること。
• その時間予算はエージェントのタイムアウト (および設定されている場合はその支出上限) にほぼ対応する — 作業の範囲を収まるように定めること。不完全でも完結した部分的な回答は、未完成の完璧な回答よりも優れている。
• 結果を先に示し、その後で根拠を示す。できなかったこととその理由を列挙する (これが return_ref の要約 — テキストの先頭 — を読む価値のあるものにする)。
• 最後に 1 行、STATUS: done、STATUS: partial、または STATUS: blocked で締めくくる。

この最後の行は result から取り出されて outcome に入ります — エージェント自身の判定であり、決定的に確認できます。"done" は完了を意味し、"partial" / "blocked" はエージェントが作業は未完了だと述べていることを意味し、その結果には何が欠けているかが示され、hint が継続方法 (通常は dispatch_session(..., session_id=...)) を明示します。テキストを読む前に outcome を読んでください。これは success を反転させることはなく、partial / blocked の結果はキャッシュされず、dispatch_parallel(..., aggregate=...) はそのようなメンバーにラベルを付けてアグリゲーターに伝えるため、ブロックされたレポートが完了したものとして合成されることはありません。エージェントが報告しなかった場合は存在しません — プロトコルがオフである (settings.dispatch_protocol: false)、response_format="json" が要求された (その場合、返信の形式は JSON フッターが規定します)、またはエージェントが単に省略した、のいずれかです。

標準命令。 エージェントごとの instructions (add_agent / update_agent または agent-dispatch update <name> --instructions "..." で設定) は、毎回のディスパッチ時に同じシステムプロンプト内のプロトコルに従います — 「読み取り専用 SQL のみ」、「タスクで指示がない限りスタックを再起動しない」、「正確なログ行で回答する」。呼び出しごとの context や、対話セッション向けに書かれたプロジェクト自身の CLAUDE.md とは異なり、これらはディスパッチされるためのルールです。

// Response (success, but the agent says it did not finish)
{
  "agent": "infra",
  "success": true,
  "result": "Restarted horizon. Could not verify the queue drained: the redis container is not reachable from here.",
  "session_id": "sess-abc-123",
  "outcome": "partial",
  "hint": "The agent reports its work is PARTIAL — read the result for what is missing, then continue in the same session via dispatch_session(agent='infra', task='Continue where you left off', session_id='sess-abc-123') or re-dispatch with what it needed."
}

dispatch_session

マルチターン: エージェントとの会話を継続します。最初の呼び出しでセッションが開始され、session_id を渡し戻すことで継続します。キャッシュされません。

パラメータ	型	必須	説明
agent	string	はい	エージェント名
task	string	はい	タスクまたはフォローアップメッセージ
session_id	string	いいえ	前回のレスポンスから — 新しいセッションの場合は空
context	string	いいえ	追加のコンテキスト
caller	string	いいえ	ディスパッチしている主体
goal	string	いいえ	より広い目的
timeout_seconds	int	いいえ	一時的なタイムアウト上書き (0 = エージェントのデフォルト、10〜7200 にクランプ)

dispatch_session はタイムアウトからの復旧経路でもあります。タイムアウトした dispatch は session_id を返します — ここに task="Continue where you left off" とともに渡すことで、最初からやり直すのではなく部分的な作業を救済できます。

Turn 1: dispatch_session("infra", "List running containers")
         → session_id: "sess-abc"

Turn 2: dispatch_session("infra", "Restart the nginx one", session_id="sess-abc")
         → agent remembers previous context

dispatch_parallel

複数のタスクを同時に実行します。逐次的な dispatch 呼び出しよりもはるかに高速です。

パラメータ	型	必須	説明
dispatches	string (JSON)	はい	{"agent", "task", "context?", "caller?", "goal?", "response_format?", "return_ref?", "summary_chars?", "timeout_seconds?", "group?"} の JSON 配列 (項目ごとの group は事前にメンバーシップを検証し、その shared_context を自動注入します)
aggregate	string	いいえ	すべての結果を 1 つの回答に統合するエージェント名

重要: dispatches は JSON 文字列であり、リストではありません。

// Input
[
  {"agent": "infra", "task": "check pod logs for errors", "caller": "backend", "goal": "debug crash"},
  {"agent": "db", "task": "are all migrations applied?", "caller": "backend", "goal": "debug crash"}
]

// Response (without aggregate)
[
  {"agent": "infra", "success": true, "result": "No errors in pod logs", ...},
  {"agent": "db", "success": true, "result": "All migrations applied", ...}
]

// Response (with aggregate="backend")
{
  "individual_results": [
    {"agent": "infra", "success": true, "result": "No errors in pod logs", ...},
    {"agent": "db", "success": true, "result": "All migrations applied", ...}
  ],
  "aggregated": {
    "agent": "backend",
    "success": true,
    "result": "Summary: all systems nominal. No pod errors, all migrations applied."
  }
}

dispatch_stream

dispatch と同じですが、エージェントの作業中にライブの進捗を表示します。長時間実行されるタスクに使用します。キャッシュされません。

進捗通知は、最新の保留中メッセージを 100 件まで保持し、それぞれ最大 300 文字に制限されます。出力がクライアントの受信速度よりも速く到着した場合、古い通知は件数の表示とともに省略されます。最終結果には影響しません。ツール呼び出しを切断またはキャンセルすると、保留中の通知は破棄され、新しい通知のバッファリングも停止します。ワーカーは処理が完了するまで並行実行スロットを保持し続けます。

パラメーターは dispatch と同じですが、return_ref/summary_chars（ストリーミングは ref モードと互換性がありません）と group（グループコンテキストの注入は dispatch および dispatch_parallel の項目単位でのみサポートされます）は異なります。

dispatch_dialogue

2 つのエージェントがマルチターンの会話を通じて協力します。キャッシュされません。

パラメーター	型	必須	説明
requester	string	はい	問題/コンテキストを持つエージェント
responder	string	はい	専門知識/ツールを持つエージェント
topic	string	はい	議論する問題または質問
max_rounds	int	いいえ	やり取りの最大ラウンド数（デフォルト: 3、最大: 10）

各ラウンドのコストは最大 2 回の dispatch です。エージェントは [RESOLVED] で完了を通知します。

// Response
{
  "resolved": true,
  "rounds": 2,
  "total_cost_usd": 0.04,
  "total_duration_ms": 12000,
  "final_answer": "Staging had 1 pending migration. Applied successfully.",
  "conversation": [
    {"agent": "db", "role": "responder", "round": 1, "message": "Which environment?", "cost_usd": 0.01},
    {"agent": "backend", "role": "requester", "round": 1, "message": "Staging", "cost_usd": 0.01},
    {"agent": "db", "role": "responder", "round": 2, "message": "Applied. [RESOLVED]", "cost_usd": 0.01}
  ]
}

add_agent

新しいプロジェクトディレクトリをエージェントとして登録します。説明を省略した場合は、プロジェクトファイルから自動生成されます。

パラメーター	型	必須	説明
name	string	はい	エージェント名（英字、数字、ハイフン、アンダースコア）
directory	string	はい	既存のプロジェクトディレクトリへのパス（~ は展開され、相対パスは解決されます）
description	string	いいえ	このエージェントができること — 空の場合は自動生成されます
timeout	int	いいえ	タイムアウト（秒）（0 = 300、これはリテラルのデフォルト値であり、settings.default_timeout ではありません）
max_budget_usd	float	いいえ	dispatch ごとの米ドルでの有限の最大コスト（0 = settings.default_max_budget_usd を継承、上限なしとなるのはそれも未設定の場合のみ）
permission_mode	string	いいえ	権限モード（例: default、plan、bypassPermissions）
allowed_tools	string	いいえ	カンマ区切りの許可ツール（例: "Bash,Read,Edit"）
disallowed_tools	string	いいえ	カンマ区切りの不許可ツール
capabilities	string	いいえ	カンマ区切りの機能ラベル（例: "docker_logs,deploy_debug"）
risky_capabilities	string	いいえ	カンマ区切りの高リスクラベル（例: "restart_services"）
instructions	string	いいえ	dispatch のたびにエージェントのシステムプロンプトに追加される常設の指示（dispatch プロトコル を参照）

update_agent

既存のエージェントの設定を更新します。空でないフィールドのみが変更されます。フィールドをクリアするには "none" を渡します。

パラメータ	型	必須	説明
name	string	はい	更新するエージェント名
description	string	いいえ	新しい説明
timeout	int	いいえ	新しいタイムアウト (0 = 変更しない)
max_budget_usd	float	いいえ	新しい予算上限 (0 = 変更しない。負の値はエージェント単位の上限をクリアし、その後 settings.default_max_budget_usd が適用されます)
model	string	いいえ	モデルのオーバーライド。クリアするには "none"
permission_mode	string	いいえ	権限モード。クリアするには "none"
allowed_tools	string	いいえ	カンマ区切り。クリアするには "none"
disallowed_tools	string	いいえ	カンマ区切り。クリアするには "none"
capabilities	string	いいえ	カンマ区切り。クリアするには "none"
risky_capabilities	string	いいえ	カンマ区切り。クリアするには "none"
instructions	string	いいえ	すべてのディスパッチに対する常設の指示 (テキストを置き換えます)。クリアするには "none"

MCP のミューテーションツールを通じてエージェントの設定を変更すると、そのキャッシュされた結果は即座に破棄されます。キャッシュキーにはエージェント設定とディスパッチのデフォルトも含まれるため、CLI、別のサーバー、または YAML を通じた編集は次のリクエストで有効になります。古い設定で終了したワーカーは、新しい設定の回答を上書きできません。変更されていないエージェントはキャッシュを保持します。

remove_agent

設定からエージェントを削除します。

パラメータ	型	必須	説明
name	string	はい	削除するエージェント名

cache_stats / cache_clear

キャッシュのヒット率とサイズを表示するか、キャッシュされたすべての結果をクリアします。

結果参照 — return_ref + fetch_result

結果テキストが大きいディスパッチ (監査、ログダンプ、コード検索) では、全文を返すと呼び出し元エージェントのコンテキストが肥大化します。代わりに return_ref=True を渡すと、小さな参照だけを取得できます:

dispatch(agent="infra", task="audit every container", return_ref=True, summary_chars=200)
  -> {"ref": "8f3a...e1", "agent": "infra", "success": true,
      "size": 14823, "summary_chars": 200,
      "summary": "Inspected 32 containers. Found 3 OOM kills in the last hour:\n- worker-3...",
      "cost_usd": 0.08, "duration_ms": 9200}

// Later, when you actually need to read the result:
fetch_result(ref="8f3a...e1")              -> full DispatchResult JSON
fetch_result(ref="8f3a...e1", max_chars=2000)  -> truncated, plus {"truncated": true, "full_size": 14823}

参照は dispatch_async ジョブと同じストレージ (~/.config/agent-dispatch/jobs/ 配下) を再利用するため、dispatch_async が返す任意の job_id は fetch_result の有効な ref にもなります。parsed_result (response_format="json" が設定されている場合) は小さく、常に参照レスポンスに直接インライン展開されます — 2 回目のフェッチは不要です。

非同期ディスパッチ — dispatch_async、dispatch_status、dispatch_wait、dispatch_cancel、dispatch_jobs、dispatch_gc

ディスパッチしたタスクに時間がかかる場合、自分のツールスロットを何分もブロックしたくはありません。非同期ディスパッチは job_id を即座に返し、準備ができたときに結果を確認できます。

// 1. fire and forget (timeout_seconds= works here too for known-long tasks)
dispatch_async(agent="infra", task="audit every container log for OOM kills today")
  -> {"job_id": "8f3a...e1", "status": "pending", "agent": "infra"}

// 2. do other work, then check progress (non-blocking)
//    `progress` is a rolling tail of what the agent is doing right now
dispatch_status(job_id="8f3a...e1")
  -> {"id": "8f3a...e1", "status": "running", "started_at": 1730000123.4,
      "progress": ["Using tool: Bash", "Scanning container logs for OOM events..."], ...}

// 3. or block until done (timeout_seconds default: 60, capped at 3600)
dispatch_wait(job_id="8f3a...e1", timeout_seconds=120)
  -> {"id": "8f3a...e1", "status": "done", "result": {"agent": "infra", "success": true, ...}}

// If the timeout fires, the job keeps running:
  -> {"id": "...", "status": "running", "timed_out_waiting": true}

dispatch_cancel(job_id) は保留中のジョブをキャンセルし、さらに、そのジョブが同じサーバーインスタンスによって起動された場合は実行中のジョブの claude プロセスグループも強制終了します（ジョブはまず cancelled としてマークされるため、ワーカーの後続の書き込みで元に戻されることはありません。部分的な作業は失われますが、進捗の末尾は保持されます）。POSIX では、そのプロセスグループ内の子孫も強制終了され、継承されたパイプと並行実行スロットが解放されます。ジョブが引き取られた後、そのプロセスが起動する前に届いたキャンセルも尊重されます。プロセスは起動するとすぐに強制終了されます。キャンセルと競合する互換性リトライは、登録された時点で強制終了されます。以前のサーバー実行によって開始された実行中のジョブは安全に強制終了できないため、完了するまでそのままにされます。レスポンスには outcome が含まれ、cancelled、cancelled_running、running（このサーバーが所有していない）、already_terminal、または not_found のいずれかになります。

非同期ワーカーは内部的にストリーミングで動作します。ジョブファイルには、アシスタントのテキストとツール使用イベントのローリング末尾（最後の 20 行、約 1 秒に 1 回の書き込み）が保持されます。dispatch_status はジョブの実行中はこれを progress として表示し、その後も事後分析のトレースとして保持します。dispatch_jobs は実行中のジョブについて last_progress を表示します。

dispatch_jobs(status?, limit=50, agent?) は最近のジョブをサマリーとして一覧表示します（pending / running / done / failed / cancelled でフィルタリングできます）。agent は完全一致する名前と照合し、設定から削除されたエージェントも含みます。両方のフィルターは limit の前に適用されます。dispatch_gc(max_age_days=7) は、しきい値より古い終了済みジョブを削除します。保留中および実行中のジョブが削除されることはありません。dry_run=True を使用すると、削除せずに対象となるジョブ ID をプレビューできます。

ジョブの状態は ~/.config/agent-dispatch/jobs/ にディスクへ永続化されます（AGENT_DISPATCH_JOBS_DIR で上書きできます）。ジョブごとに 1 つの JSON ファイルとして、オーナーのみが読み書きできる権限（0o600）でアトミックに書き込まれます。ジョブの実行中でも安全に読み取りや ls ができます。呼び出し元が指定する job_id は、ファイルアクセスの前に 32 文字の 16 進数として検証されます（パストラバーサル対策）。起動時に、サーバーはクラッシュしたインスタンスが放置したジョブを復旧します。1 時間以上停止している running のジョブと、24 時間以上停止している pending のジョブは failed としてマークされ、永遠にポーリングされ続けることを防ぎ、dispatch_gc で回収可能になります。（pending のしきい値が意図的に長いのは、ジョブディレクトリが実行中のすべてのサーバーで共有されるため、別のサーバーの並行実行制限の後ろに並んだジョブが掃き出されてはならないからです。）

非同期を使うべき場合	dispatch を使うべき場合
長時間のタスク（数分）— 作業を続けたい	短時間のタスク — 今すぐ答えが必要
後で回収する複数の長時間タスク	複数の短時間タスク → dispatch_parallel
キャッシュを気にしない（各呼び出しは新しいジョブ）	デフォルトでキャッシュ — 同一のリクエストは無料

どのツールを使うべきか

シナリオ	ツール
別のプロジェクトへのちょっとした単発の質問	dispatch
フォローアップを伴う多段階のワークフロー	dispatch_session
複数のエージェントから同時に回答を得たい	dispatch_parallel
長時間のタスクで、進捗を確認したい	dispatch_stream
2 つのエージェントが連携する必要がある	dispatch_dialogue
複数のエージェントから統合されたサマリーが必要	aggregate を指定した dispatch_parallel
長時間のタスク — ツールの枠を塞ぎたくない	dispatch_async + dispatch_wait
ブロックせずに進捗を確認する	dispatch_status
長時間かかると分かっている単発タスク	timeout_seconds=... を指定した任意の dispatch ツール
dispatch がタイムアウトした	エラーに含まれる session_id を指定した dispatch_session
関連するプロジェクト群をまとめて調整する	グループを定義し、dispatch(..., group=name) を実行する
どのエージェントが作業セットを形成しているか確認する	list_groups / inspect_group

エラーからの復旧

失敗は決定的です。まず success を確認し、次に error_type で分岐します。

error_type	意味	復旧
permission	ツール呼び出しが拒否された	update_agent(name, allowed_tools="Bash,Read")（最小権限）または update_agent(name, permission_mode="bypassPermissions") を実行してから再ディスパッチします。error テキストには、正確な修正方法のヒントが含まれます。
timeout	タイムアウト時にプロセスグループが強制終了された	部分的な作業を再開します: dispatch_session(agent, "Continue where you left off", session_id=<from the error text>)。または、より大きな timeout_seconds= で再試行します。ジャーナルに履歴があれば、このエージェントの p90 をカバーできたはずの値がエラーに示されます。あるいは dispatch_async を使用します。通常のディスパッチとストリーミングディスパッチのどちらも、終了前に受信した完全な CLI 結果を保持します。成功した結果にはクリーンアップの hint が含まれます。部分的な出力はタイムアウトのままです。
not_found	エージェントディレクトリまたは claude CLI が見つからない	list_agents() → healthy を確認します。既存のパスでエージェントを再追加するか、agent-dispatch doctor を実行して不足しているものを特定します。
recursion	ディスパッチのネストが max_dispatch_depth（デフォルト 3）を超えた	ディスパッチされたエージェントからディスパッチしないでください。ネストが意図的な場合は、設定で max_dispatch_depth を引き上げます。
budget	claude CLI が max_budget_usd の支出上限でセッションを終了した — 回答は不完全	上限を引き上げる（update_agent(name, max_budget_usd=2.0)）、より安価な model に切り替える、またはタスクを分割します。部分的なセッションは再開可能です: dispatch_session(agent, "Continue where you left off", session_id=<from the result>)。
usage_limit	Claude のアカウントが使用量/レート制限に達した — このエージェントではなく、課金もされていない	error テキストに示されたリセットを待ちます。別のエージェントをディスパッチしても回避策にはなりません。すべてのエージェントは同じアカウントで実行されるためです。負荷時に繰り返す場合は、settings.max_concurrency を下げます。
cli_error	claude サブプロセスからのその他のエラー	error テキストを読みます。環境の問題については agent-dispatch doctor を実行します。一時的なものであれば 1 回再試行します。

success: true とともに届く 3 つのソフトシグナル:

• denied_tools + hint — エージェントは完了しましたが、一部のツール呼び出しがブロックされました。結果が不完全である可能性があります。アクセスを許可し（permission の行を参照）、再ディスパッチします。
• outcome: "partial" / "blocked" — 完了しなかったというエージェント自身の判定です。結果には不足しているものが示され、hint には同じセッションで続行するための dispatch_session(...) 呼び出しが含まれます。キャッシュされないため、原因を修正した後の再ディスパッチは新規に実行されます。
• parsed_result: null かつ response_format="json" — 応答が有効な JSON ではありませんでした。生のテキストは依然として result にあります。注意点: 準拠できないエージェントは {"error": "<reason>"} を返しますが、これは正常にパースされるため、parsed_result に "error" キーがないかも確認してください。
• budget_exceeded: true — CLI が実行を停止することなく、cost_usd がエージェントの max_budget_usd（または設定のデフォルト）を超えました（最後のターンで上限を超えることがあります）。ディスパッチは失敗していません — 費用はすでに発生しています — が、暴走したエージェントが可視化されました。タスクを厳格化する、より安価なモデルを選ぶ、または予算を引き上げます。CLI が実際に停止した実行は、代わりに error_type: "budget" で失敗します。

ツールレベルのエラー（不明なエージェント、不正な入力）は、DispatchResult の代わりにプレーンなエンベロープを返します:

{"error": "Unknown agent: 'foo'. Available: infra, db, monitoring"}

設定

設定は ~/.config/agent-dispatch/agents.yaml にあります（上書き: AGENT_DISPATCH_CONFIG 環境変数）:

agents:
  infra:
    directory: ~/projects/infra
    description: "Infrastructure agent. MCP: portainer."
    timeout: 300            # seconds, default: 300
    capabilities:           # capability labels, shown in list_agents
      - docker_logs
      - deploy_debug
    risky_capabilities:     # high-risk labels, surfaced for visibility
      - restart_services
    # instructions: |       # standing orders, appended to the system prompt on every dispatch
    #   Read-only: never restart or redeploy unless the task says so.
    #   Quote exact log lines with timestamps.
    # model: sonnet         # optional model override
    # max_budget_usd: 1.0   # cost limit per dispatch
    # permission_mode: bypassPermissions  # one of: default | plan | bypassPermissions
    # allowed_tools:        # restrict which tools the agent can use
    #   - Read
    #   - Grep
    # disallowed_tools:     # block specific tools
    #   - Write

# Optional: bundle related agents into a cross-project working set.
# A descriptive layer — no router; the orchestrating session coordinates
# with the normal dispatch tools. See the Groups section above.
groups:
  shop:
    # ORCHESTRATOR-facing: how to coordinate the group. Surfaced by
    # list_groups/inspect_group, NEVER injected into a member's prompt.
    description: "After a code change: deploy via infra, then verify via analytics."
    # MEMBER-facing facts, auto-prepended to dispatch(..., group="shop").
    shared_context: |
      Prod runs in Portainer stack "shop". Metrica counter 12345.
    members:                # reference agents above (many-to-many)
      - agent: infra
        use_for: deploy, restart, container logs
      # - agent: backend
      #   use_for: orders/payments endpoints

settings:
  default_timeout: 300
  # default_permission_mode: bypassPermissions  # inherited by all agents
  # default_allowed_tools:                      # inherited when agent has none
  #   - Bash
  #   - Read
  #   - Edit
  max_dispatch_depth: 3     # recursion protection
  max_concurrency: 5        # max parallel claude -p processes per server, across all tools
  # dispatch_protocol: true # send every agent the dispatch protocol (non-interactive,
  #                         # time budget, STATUS line → `outcome`). false = raw claude -p.
  # usage_log: true         # record every dispatch in usage.jsonl (cost, duration, outcome).
  #                         # Powers `agent-dispatch stats`, the `typical` block and the
  #                         # measured timeout suggestion. false = record nothing.
  # job_retention_days: 30  # 0 (default) = never prune. See "Job retention" below.
  cache:
    enabled: true
    ttl: 300                # seconds
    max_size: 1000          # max cached entries; oldest evicted first (FIFO)

設定はツール呼び出しのたびに再読み込みされます — 再起動せずにエージェントを追加できます。

使用ジャーナル — あなたのフリートが実際にいくらかかっているか

ディスパッチのたびに、~/.config/agent-dispatch/usage.jsonl に 1 行が追記されます (AGENT_DISPATCH_USAGE_LOG で上書き可能): エージェント、成功、コスト、所要時間、 ターン数、outcome、エラータイプ、呼び出し元。キャッシュヒットも記録され、cached と フラグが付くので、レポートでキャッシュがどれだけ節約しているかを示せます。

$ agent-dispatch stats --days 7
Usage (last 7 day(s))
  dispatches: 33, 1 served from cache
  spend:      $13.0390
  duration:   median 87s, p90 2m40s, max 10m00s
  outcomes:   blocked 1, done 27, partial 3
  failures:   timeout 1, usage_limit 1

Per agent
  analytic           18 runs  $  8.9441  median  2m04s  p90  2m51s
      done 15, partial 3
  gitlab             12 runs  $  3.7949  median    60s  p90    86s
      done 12  |  1 cached

--agent NAME で絞り込み、--json で同じレポートを JSON として出力します。

このジャーナルが、他に 3 つの仕組みを機能させています: list_agents / inspect_agent の typical ブロック、倍々の推測値ではなくエージェントの実際の p90 から 導出された値を示すタイムアウトエラー、そして「どのエージェントが高コストか」への 答えです。設定で usage_log: false にすると無効にできます。

知っておく価値のある性質: ファイルは所有者のみアクセス可能 (0o600) です。各レコードは PIPE_BUF のはるかに下に収まる単一の O_APPEND 書き込みであるため、CLI と実行中の すべてのサーバーがロックなしで共有でき、行が壊れることもありません。約 2 MB で usage.jsonl.1 にローテーションし、2 世代を保持するため、常に約 4 MB に収まります。 書き込みに失敗してもディスパッチが失敗することはありません。

ジョブの保持

すべての dispatch_async および すべての dispatch(..., return_ref=True) は ~/.config/agent-dispatch/jobs/ にレコードを書き込み、それを自動的に削除するものは 何もありません — dispatch_gc を手動で実行する必要があります。したがって、この ディレクトリは無制限に増大し、dispatch_jobs と、サーバー起動のたびに実行される 古いジョブのリカバリが、その中のすべてのファイルを読み込んで解析します。

サーバー起動時に、終端状態 (done/failed/cancelled) のレコードのうち N 日より古いものを 削除するには、job_retention_days を設定します:

settings:
  job_retention_days: 30

デフォルトは 0 — 無効 — です。これらのレコードは過去のディスパッチのあなた自身の 履歴であり、削除は元に戻せないためです。保留中および実行中のジョブは決して 触れられません。

agent-dispatch gc --days N と dispatch_gc ツールは、同じルールを単発で適用します。 削除する前に、対象となるレコードをプレビューできます:

agent-dispatch gc --days 30 --dry-run
agent-dispatch gc --days 30

--dry-run は --all とも併用できます。MCP での同等物は dispatch_gc(max_age_days=30, dry_run=True) で、dry_run: true、purged: 0、 would_purge、job_ids、max_age_days を返します。 プレビューはスナップショットです。削除時には対象条件が再度チェックされるため、ジョブの 完了に伴ってその件数は変わることがあります。読み取り不能なレコード、無効なタイムスタンプ、 内部 ID がファイル名と異なるレコードはスキップされ、確認用に保持されます。

自動説明

--description なしの agent-dispatch add は、以下から説明を生成します:

• CLAUDE.md — 最初の意味のある段落 (優先)
• README.md — 最初の実質的な行 (フォールバック)
• pyproject.toml / package.json — プロジェクトの説明
• .mcp.json — MCP サーバー名を列挙
• スタック指標 — Docker、Rust、Go、Python、Node.js
• DB 指標 — Prisma、Alembic、マイグレーション

明示的なケイパビリティ

自動説明は便利ですが、明示的な capabilities によって、各エージェントが何のためのものかが より明確になります。エージェントに短い snake_case のタスクラベルを追加します:

agent-dispatch update infra \
  --capabilities docker_logs,deploy_debug \
  --risky-capabilities restart_services

list_agents と inspect_agent は capabilities と risky_capabilities を表示するので、 呼び出し元は一目で適切なエージェントを選べます — risky_capabilities はよりリスクの高い 能力 (例: サービスの再起動) にフラグを立て、追加の精査を促します。

仕組み

Your Claude Code session
  │
  ├─ dispatch("infra", "find errors", caller="backend", goal="debug crash")
  │
  ▼
agent-dispatch MCP server
  ├─ cache check → hit? return cached result
  ├─ shared process limit → bound concurrency across all dispatch tools
  └─ subprocess.Popen(["claude", "-p", ...], cwd=~/projects/infra/)
       │
       ▼
     New Claude Code session in ~/projects/infra/
       ├─ Inherits: CLAUDE.md, .mcp.json, project tools
       ├─ System prompt += dispatch protocol + the agent's standing `instructions`
       ├─ Receives structured prompt with goal/caller/context/task
       └─ Returns result (+ its own STATUS → `outcome`) → cached when complete
                    │
                    └─ one line appended to usage.jsonl (cost, duration, outcome)

安全性

• 再帰保護 — 環境変数 AGENT_DISPATCH_DEPTH がネストを追跡します。デフォルトの上限: 3。サブプロセスの境界をまたぐベストエフォートです（SECURITY.md を参照）。
• 引数インジェクションガード — - で始まる構造化された CLI フィールド（session_id、model、permission_mode、ツール名）は拒否されるため、余分な claude フラグを密輸できません。
• パストラバーサルガード — 呼び出し側が指定する job_id/ref の値は、ファイルシステムにアクセスする前に 32 文字の 16 進数として検証されます。
• オーナー専用の状態 — ジョブファイル、agents.yaml、使用量ジャーナル、サーバーレジストリはすべて 0o600 で書き込まれ、それらのディレクトリは 0o700 です。
• コスト制御 — エージェントごとまたはグローバルな max_budget_usd は --max-budget-usd として claude CLI に渡されるため、暴走したディスパッチは上限で停止し、error_type: "budget" と再開可能な session_id を返します。停止せずに予算を超過してしまったオーバーシュートは、budget_exceeded: true とヒントによって事後にフラグが立てられます。
• 並行性 — max_concurrency（デフォルト: 5）は、1 つのサーバープロセス内のすべてのディスパッチツールにわたる並列 claude -p プロセスを上限設定します。通常・ストリーミング・バックグラウンドのディスパッチは同じ制限を共有し、待機中の呼び出しは到着順に処理されるため、バックグラウンドジョブのキューが対話的な呼び出しを枯渇させることはありません。待機中の呼び出しをキャンセルしてもそのプロセスが開始されることはありません。すでに開始された通常またはストリーミングの呼び出しをキャンセルしても、ワーカーが終了するまでそのスロットは占有されたままです。変更された制限を再読み込みしても占有中のスロットは保持されます。制限を下げると既存の作業は完了でき、新しい起動は容量が利用可能になるまで保留されます。別々のサーバープロセスはそれぞれ独自の制限を持ちます。
• タイムアウト — エージェントごとまたはグローバル（デフォルト: 300 秒）。通常のディスパッチとストリーミングのディスパッチはどちらも、エージェントを独自のプロセスグループで実行します。POSIX では、期限に達するとそのグループが強制終了され、出力パイプを継承した子孫も含まれます。通常のディスパッチでは、子孫が意図的にグループから離脱した場合、クリーンアップは追加で 1 秒に制限されます。その離脱したプロセスはグループの及ぶ範囲外です。完全な CLI 結果はクリーンアップのタイムアウトを生き延び、成功した結果にはヒントが付きます。
• キャッシュ — 同じエージェント設定とディスパッチのデフォルトのもとでの同一の (agent, task, context, caller, goal, response_format) リクエストは、キャッシュされた結果を返します（cache.max_size を上限とし、最も古いエントリから削除されます）。キャッシュされるのはクリーンな成功のみです。失敗、denied_tools を含む結果、budget_exceeded のフラグが立った結果、およびエージェント自身が partial / blocked と報告した結果はキャッシュされません。そのため、ドキュメントに記載されている「アクセスを許可する / 上限を引き上げてから再ディスパッチする」という復旧手段に、古い機能不全の回答が返されることはありません。エージェントの設定を変更すると、そのエントリは無効になります。セッションと対話がキャッシュされることはありません。group= ディスパッチはグループの shared_context を context に折り込むため、異なるグループは別々にキャッシュされ、通常のディスパッチは影響を受けません。
• 永続的な設定 — agents.yaml はアトミックに書き込まれる（一時ファイル + リネーム）ため、中断された書き込みがそれを切り詰めることはありません。すべての変更経路（CLI と MCP サーバーの両方）はプロセス間のアドバイザリロックも取得するため、並行する編集が互いのエージェントを失うことはありません。このロックは設計上ベストエフォートです。10 秒待機した後、警告をログに記録してそのまま続行します。これは、ロックを保持したまま固まったプロセスが MCP サーバーを凍結させてはならないためです。そのため、激しく競合する設定では更新の消失は起こり得ますが、切り詰めは起こりません。

完全な脅威モデル（bypassPermissions のエスカレーションリスクやオンディスクのジョブファイルを含む）については SECURITY.md を参照してください。

CLI

コマンド	説明
agent-dispatch init	設定を作成し、Claude Code に MCP サーバーを登録します
agent-dispatch add <name> <dir>	エージェントを追加します（説明は自動生成されます）
agent-dispatch update <name>	エージェントの設定（権限、タイムアウト、モデル、--instructions など）を更新します
agent-dispatch remove <name>	エージェントを削除します
agent-dispatch list	エージェントをヘルスステータスと権限とともに一覧表示します
agent-dispatch group <add|list|inspect|update|remove>	グループ（プロジェクトをまたぐエージェントの作業セット）を管理します
agent-dispatch describe <name>	1 つのエージェントの完全な設定（トライステートのツール、プロジェクトファイル）を表示します
agent-dispatch test <name> [task] [--stream]	ディスパッチでエージェントをテストします（--stream でリアルタイムの進捗を表示）
agent-dispatch stats [--days N --agent X --json]	ディスパッチにかかるコスト: エージェントごとの支出、所要時間、結果、失敗
agent-dispatch doctor [--json --strict]	インストール、古いサーバー、MCP 登録、エージェントのヘルス、グループメンバーシップを診断します。--strict を指定すると警告でも失敗します
agent-dispatch jobs [--status STATUS --agent NAME --limit N --json]	直近のジョブ概要を一覧表示します（return_ref とともに保存された結果を含む）
agent-dispatch job <id> [--json]	1 つのジョブを表示します。--json は完全なレコードを切り詰めずにエクスポートします
agent-dispatch cancel <id>	保留中のジョブをキャンセルします（実行中のジョブ: dispatch_cancel MCP ツールを使用してください）
agent-dispatch gc [--days N | --all] [--dry-run]	N 日より古い終了済みジョブを削除します（デフォルト 7、--all はすべての古さのジョブを削除）。--dry-run は削除せずにプレビューします
agent-dispatch serve	MCP サーバーを起動します（stdio、Claude Code が使用）

スクリプトからインストールを確認するには:

agent-dispatch doctor --json --strict > diagnostics.json

レポートには schema_version: 1、全体の status（ok、warn、fail のいずれか）、issues と warnings の件数、そして checks 配列が含まれます。各チェックには section、status、message、および修復手順や補足情報を含む details 配列があります。チェックが失敗しても JSON は出力されます。失敗は終了コード 1 で終了し、警告は --strict が設定されていない限り終了コード 0 で終了します。同じチェックと終了ポリシーが通常の人間が読める出力にも適用されます。これはインストールと設定をチェックするものであり、有料のディスパッチは実行しません。

スクリプトから履歴を確認したり、完全な結果を保存したりするには:

agent-dispatch jobs --agent infra --status failed --limit 10 --json
agent-dispatch job <job_id> --json > job.json

jobs --json は dispatch_jobs と同じ形式のコンパクトな概要の配列を返します。一致するジョブがない場合は [] を返します。各概要には ID、エージェント、ステータス、タスクの先頭 120 文字、およびタイムスタンプが含まれます。結果のコスト、成功、結果、エラータイプ、最新の実行中の進捗は、利用可能な場合に含まれます。job --json は保存された完全なジョブを返します（タスク/コンテキスト、進捗、結果テキスト、構造化された結果、セッション ID、および存在する場合は復元のヒントを含む）。どちらの形式も Unicode を保持します。失敗したジョブを読み取っても正常に終了します。ディスパッチの結果を判断するには、その status と result.success を確認してください。存在しない、または無効なジョブ ID やストレージのオープン失敗は {"error": "..."} を終了コード 1 とともに返します。無効なコマンドラインオプションは Click によって stderr に報告されます。

無効または非有限のコストメタデータは不明として扱われ、結果のエクスポートから除外されます。これは保存された結果テキストを隠すものではありません。使用状況の概要は使用できない数値測定を無視し、doctor はサーバーの開始タイムスタンプが読み取れない場合に稼働時間を省略します。

要件

• Python >= 3.10
• Claude Code CLI がインストールされ、認証済みで、PATH 上にあること（確認: claude --version）

ライセンス

MIT