Chorus デーモンを運用する

フォアグラウンドのデーモン接続を確認した後に、このガイドを使ってください。コマンドは対応する常駐バックエンド、つまり Claude Code、Codex、Kiro、Pi に適用されます。

デーモンがアクセスできる範囲を選ぶ

各 --cwd は、一つの作業ディレクトリを Chorus 上の別々のターゲットとして登録します。

chorus daemon \
  --agent claude-code \
  --cwd ~/work/project-a \
  --cwd ~/work/project-b \
  --chorus-only

--cwd がないと、Chorus はコマンドを起動したディレクトリを使います。繰り返し指定できる --browse-root オプションは、ユーザーがより広いルートの下でディレクトリを選ぶ必要があるときにだけ使ってください。browse root は探索を許可するだけで、すべてのディレクトリをオンライン接続として登録するわけではありません。

プロジェクトのエージェントの作業ディレクトリを固定するとき、そのパスはこのデーモンが提供するものでなければなりません。このデーモンの cwds の集合に含めて、固定したディレクトリがオンライン接続に解決されるようにしてください。

`daemon.json` を構成する

デーモンは設定を ~/.chorus/daemon.json から読み込みます。よくある単一エージェントの場合、これはエージェントの認証情報とランタイムのオプションの両方を保持する、単一のフラットな JSON オブジェクトです。1 つのデーモンで複数のエージェントを動かすには、代わりにそれらを agents 配列に列挙します（後述の「1 つのデーモンで複数のエージェントを動かす」の節を参照）。いずれの形式でも、0600（所有者のみ読み書き可）で、一時ファイルを書いてからリネームする原子的な方式で書き込まれるため、書き込み途中でクラッシュしても切り詰められたファイルが残ることはありません。パスは ~/.chorus/daemon.json（ホームディレクトリから解決）に固定されており、ファイル自体を移動させる環境変数はありません。

フィールド

フィールド	型	意味
`url`	string	Chorus サーバーの URL。
`apiKey`	string	エージェントの API キー（`cho_…`）。
`agentUuid`	string	認証済みエージェントの UUID（参考情報）。
`agentName`	string	認証済みエージェントの名前（参考情報）。
`cwds`	string[]	このデーモンが提供する作業ディレクトリ。各パスは一つの独立したオンライン接続です。
`browseRoots`	string[]	リモートの作業ディレクトリ探索に公開するルート。browse root は接続を作りません。
`agent`	string	起こすローカルバックエンド：`"claude-code"`、`"codex"`、`"kiro"`、`"pi"`。
`sigintTimeoutMs`	number	`SIGINT` の後、起こされたエージェントが強制終了されるまでの猶予時間（ミリ秒）。既定値は `10000`。
`agents`	object[]	任意。 1 つのデーモンで複数の独立したエージェントを動かします。各エントリはそのエージェントについて上位フィールドを上書きします。後述の「1 つのデーモンで複数のエージェントを動かす」を参照。

chorus login と chorus daemon install の後の最小限のファイル。

{
  "url": "https://chorus.example.com",
  "apiKey": "cho_REDACTED",
  "agentUuid": "8a1c…",
  "agentName": "Build Agent",
  "cwds": ["/home/demo/work/project-a"],
  "browseRoots": ["/home/demo/work"],
  "agent": "claude-code",
  "sigintTimeoutMs": 10000
}

ファイルはどう作られるか

chorus agents add は、通常このファイルが最初に作られる方法です。設定された各エージェントの認証情報を検証し、agents 配列のエントリとして書き込みます。エージェントランタイムを接続するを参照してください。
chorus login は URL とキーを検証してから、単一のフラットなエージェントとして url、apiKey、agentUuid、agentName を書き込みます。
chorus daemon install はさらに cwds、browseRoots、agent を書き込みます（これらがまだ設定されていない場合は、提供するディレクトリとバックエンドを尋ねます）。
端末で初めて chorus daemon を実行すると、欠けている認証情報を対話的に補完して書き込みます。

ファイルはどう更新されるか

どの書き込み側も浅いマージを行います。新しいフィールドは、ディスク上の既存の内容の上にマージされ、無関係なフィールドは保持されます。chorus login を再実行すると、cwds、agent、sigintTimeoutMs を消さずに認証情報だけを更新します。chorus daemon install を再実行すると、認証情報を捨てずに提供する集合を更新します。ファイルが欠けているか壊れている場合は空のオブジェクトとして扱われるため、再ログインは失敗せず常に有効なファイルを生成します。

フィールド、フラグ、環境変数

各オプションは三通りの方法で与えられます。優先順位はフラグ、次に環境変数、最後に daemon.json なので、一度きりのフラグや環境変数による上書きをファイルに書く必要はありません。

対象	`daemon.json` のフィールド	CLI フラグ	環境変数
サーバー URL	`url`	`--url`	`CHORUS_URL`
API キー	`apiKey`	`--api-key`	`CHORUS_API_KEY`
作業ディレクトリ	`cwds`	`--cwd`（繰り返し可）	`CHORUS_DAEMON_CWDS`
browse root	`browseRoots`	`--browse-root`（繰り返し可）	`CHORUS_DAEMON_BROWSE_ROOTS`
バックエンド	`agent`	`--agent`	`CHORUS_AGENT`
SIGINT 猶予	`sigintTimeoutMs`	`--sigint-timeout`	`CHORUS_DAEMON_SIGINT_TIMEOUT`
権限モード	(永続化されない)	`--yolo` / `--chorus-only`	`CHORUS_YOLO` / `CHORUS_CHORUS_ONLY`

権限モードは意図的に daemon.json に保存されません。起動時に --chorus-only を渡すか（あるいは CHORUS_CHORUS_ONLY=1 を設定）してください。インストールされたサービスは --chorus-only をファイルではなくそのユニットに取り込みます。

1 つのデーモンで複数のエージェントを動かす

1 つの chorus daemon プロセスは、複数の完全に独立したエージェントを同時に動かすことができます。ペルソナ、権限、アカウント、さらにはバックエンドが異なっていてもかまいません。エージェントごとに別々のデーモンを走らせる必要はありません。それらを agents 配列に列挙します。各エントリが 1 つのエージェントです。

{
  "url": "https://chorus.example.com",
  "sigintTimeoutMs": 8000,
  "agents": [
    { "apiKey": "cho_alpha", "agentType": "claude-code", "cwds": ["/home/demo/project-a"] },
    { "apiKey": "cho_beta", "agentType": "kiro", "cwds": ["/home/demo/project-b"], "permissionMode": "chorus" }
  ]
}

上位のフィールドはすべて既定値になり、エージェントに設定したフィールドはそのエージェントだけを上書きします。各エージェントは、自分の（キーによる）アイデンティティ、自分の接続（cwds ごとに 1 つ）、自分の起動キュー、自分のバックエンドを持ちます。したがって、それぞれ独立して起こされ実行され、あるエージェントの失敗が他のエージェントを妨げることはありません。サーバー上では、各エージェントは agent・ホスト・ディレクトリをキーとして、設定 → エージェント（Settings → Agents）に独立した接続として表示されます。エージェントは同じ作業ディレクトリを共有することもできますが、デーモンはそれらを直列化しないため、1 つの git ツリー内で衝突する作業を並行して行うのは避けてください（別々のブランチや worktree を使ってください）。

エージェントごとのフィールド

フィールド	意味
`apiKey`（必須）	エージェントの `cho_` キー。そのアイデンティティを決めます。
`url`	Chorus サーバー（エージェントごとに異なってよい。別のサーバーや会社）。
`agentType`	`claude-code`、`codex`、`kiro`、`pi`（バックエンドは混在可）。
`cwds`	このエージェントが提供する作業ディレクトリ（それぞれ 1 接続）。
`permissionMode`	`yolo` または `chorus`。
`maxConcurrency`	このエージェント自身の起動同時実行数の上限（既定値 `4`）。
`sigintTimeoutMs`	中断エスカレーションの猶予時間（ミリ秒）。
`browseRoots`	ディレクトリ探索の許可リスト。

もう 1 つのエージェントを追加する

chorus login --add は新しいキーを検証し、別のエージェントとして追加します。フラットなファイルで初めて --add を使うと、既存の認証情報を agents[0] に移し、新しいキーを agents[1] として追加します。重複するキーは拒否され、既存のエージェントが上書きされることはありません。
chorus daemon install --add はインストールウィザードをループさせ、一度の実行で複数のエージェントを追加できます（端末のみ）。
手動編集 ~/.chorus/daemon.json は常にサポートされています。

ファイルを編集したらデーモンを再起動し（chorus daemon restart）、設定 → エージェント（Settings → Agents）で各エージェントが表示されることを確認してください。

各バックエンドはどのように自分のキーを受け取るか

各エージェントは自分のキーで認証しますが、そのキーが起こされたサブプロセスにどのように届くかはバックエンドによって異なります。

Claude Code — 自動です。デーモンは起動ごとに、そのエージェントの URL とキーを含む MCP 設定を書き出します。設定は不要です。
Kiro — 環境変数を通じて自動です。インストールされた mcp.json は ${CHORUS_URL} と ${env:CHORUS_API_KEY} を参照し、デーモンが起動ごとにそれらをエクスポートするため、各 Kiro エージェントは自分のキーで認証します。
Codex — 環境変数を通じて自動です。chorus agents add は Codex をキーレスに設定します。CHORUS_URL / CHORUS_API_KEY / CHORUS_AGENT_PROFILE を ~/.codex/.env（Codex が起動時に読み込む）に書き込み、config.toml に bearer_token_env_var = "CHORUS_API_KEY" を設定するため、Codex はリテラルを埋め込む代わりに環境変数からキーを読みます。デーモンは起動ごとに各エージェント自身のキーを注入するため、1 つのデーモン内の複数の Codex エージェントがそれぞれ自分自身として認証します。
Pi — 環境変数を通じて自動です。デーモンは起動ごとに各エージェント自身の CHORUS_URL / CHORUS_API_KEY / CHORUS_AGENT_PROFILE を、起こされた pi セッションにエクスポートし、chorus-pi 拡張がそれらを読み取るため、各 pi エージェントは自分のキーで認証します。

Linux サービスをインストールする

Linux では、確認済みの構成をユーザーサービスとしてインストールします。

chorus daemon install \
  --agent claude-code \
  --cwd ~/work/project-a \
  --chorus-only

インストーラーはサービスを直ちに起動し、ユーザーがログインしたときに開始するよう設定します。サービスが保存済みの認証情報を読めるように、先に chorus agents add（または chorus login）を実行してください。あるいは、この起動サービスを同じ手順で一緒にインストールするには、chorus agents add に --daemon-autostart を渡してください。

起動されるエージェントに必要な資格情報を渡す

デーモンが起こされたエージェントに注入するのは Chorus 接続（CHORUS_URL、CHORUS_API_KEY、CHORUS_AGENT_PROFILE）だけで、モデルプロバイダーのキーは決して注入しません。バックエンドがモデルプロバイダーの資格情報を環境変数から読み取る場合、それらはデーモン自身の環境に存在している必要があります。systemd --user サービスはクリーンな環境で始まり、ログインシェルでエクスポートした変数を継承しないため、ドロップインでサービスに設定してから再起動してください。

[Service]
Environment=EXAMPLE_PROVIDER_API_KEY=…

systemctl --user daemon-reload && systemctl --user restart chorus-daemon

プロバイダー認証をファイルから読み取るバックエンド（例えば ~/.claude / ~/.codex の Claude Code や Codex）は、デーモンの HOME が正しく設定されていればよく、インストールされたユニットが既にそれを行っています。

日常の運用には次のコマンドを使います。

chorus daemon status
chorus daemon logs
chorus daemon restart
chorus daemon stop
chorus daemon uninstall

認証情報、作業ディレクトリ、バックエンド、権限モードを変更した後は、サービスを再インストールまたは再起動し、設定 → エージェント（Settings → Agents）で接続を確認してください。

サービスなしで実行する

短命の接続なら、chorus daemon をフォアグラウンドのままにします。デタッチモードも使えます。

chorus daemon -d --agent codex --cwd ~/work/project-a --chorus-only

同じ status、logs、restart、stop のコマンドで管理します。デタッチモードを、別途書いたプロセススーパーバイザーと組み合わせないでください。

運用状態を確認する

コマンドラインと Web の両方の状態を使います。

chorus daemon status を実行します。
chorus daemon logs で直近の出力を確認します。
設定 → エージェント（Settings → Agents）で、期待する各作業ディレクトリがオンライン（Online）であることを確認します。
小さなテストセッションを開始し、意図したディレクトリを対象にしていることを確認します。

ログにはパス、プロンプト、コマンドの出力が含まれることがあります。共有する前に機微な値を削除してください。失敗した場合はエージェント接続のトラブルシューティングへ進んでください。