compozy/compozy：CompozyOS v0.3 beta の常駐デーモン

CompozyOS はエージェント周辺を一つの runtime に寄せる

compozy/compozy の README 見出しは CompozyOS である。エージェントへプロンプトを送ること自体は誰でもできる、一方で連続稼働はまだエンジニアリング案件だ、と書き出す。ループ、トリガ、cron、メモリ、権限、承認、観測、それらを繋ぐ糊スクリプトを一つの製品にまとめる、というのが位置づけだ。想定読者は開発者と技術オペレータ。動かす CLI の例として Claude Code、OpenClaw、Hermes を挙げ、ACP 互換なら同じ daemon 所有状態を操作できる、と説明する。

ハイライトは Create、Automate、Supervise に分かれる。セッション、エージェント、Loop、capabilities は一度書いて再利用するオブジェクト。cron、webhook、トリガは端末を開かずに仕事を続ける。承認、権限、run 状態、成果物、エージェント活動はバックグラウンド実行中も検査できる。Sessions と Loop runs は daemon の所有物なので、クライアントを閉じても消えない。

ローカルファーストが既定で、Go の単一バイナリと SQLite ストアが実行状態をオペレータのマシンに置く。Gateway でリモート面を明示的に開く。Compozy Network はセッションがピアを見つけ、型付きメッセージを交わし、委譲し、receipt で閉じる経路で、プロトコル名は compozy-network/v0。ライセンスは MIT。最新タグは素材上 v0.3.0-beta.21（2026-08-27）。

糊スクリプトを自分で量産しているチームほど、README の「すでに周囲が組み上がっている」という売り文句が刺さる。逆に、単発のプロンプトをターミナルで打つだけなら daemon は過剰である。ACP 互換と書いてある以上、非対応の CLI を無理に繋ぐ手順は README に無い。メモリと承認がプラグインではなくコアオブジェクトだ、という一文は、拡張を足す前に標準の状態モデルを学ぶ理由になる。SQLite が既定なのは、運用者がディスク上のファイルとして状態をバックアップできる、という意味でもある。外部プロバイダが境界を持つ場合だけ、その限りではない。

v0.3 beta と legacy/v0.2 の並走

WARNING ブロックは v0.3 系が beta であること、以前の v0.2.15 製品は deprecated で critical fixes のみ、保守ブランチは legacy/v0.2 であること、を先に出す。既存の v0.2 導入を置き換える前に MIGRATION_GUIDE.md を読め、と指示している。beta を本番 SLA の下に置く前提は README に無い。

Homebrew の compozy formula は beta 期間中も deprecated な v0.2 を出し続けるため、Installation 節から意図的に省かれている。v0.3.0 安定で formula が戻る、と README は書く。go install github.com/compozy/compozy@<release-tag> では、Go の @latest がまだ v0.2 安定を解決するので、GitHub の latest release に出ているタグを明示する必要がある。

v0.2 の tasks run パイプラインは v0.3 では復活しない。Task Schema v2 節がそう明記する。旧ホームディレクトリを新ホームへコピーして済ませる移行は、configuration guide が禁じる経路だ。

critical fixes のみ、という保守方針は、v0.2 へ新機能を期待するな、という合図だ。beta 期間中に schema がまた動く可能性は README が否定していない。MIGRATION_GUIDE.md を読まずにバイナリだけ差し替えると、tasks run が消えたことに後から気づく。Homebrew で入れる人が v0.3 を得られないのは欠陥ではなく、README が選んだ欠番である。go install のタグを付け忘れると、気づかず v0.2 に戻る。

install.sh の Sigstore と npm @compozy/cli@beta

Verified installer は curl -fsSL https://compozy.com/install.sh | sh で、公開済みの最新 beta をピンし、Sigstore provenance を検証してから macOS または Linux にバイナリを置く。NPM 経路は npm install -g @compozy/cli@beta。ソースは git clone https://github.com/compozy/compozy.git のあと go build -o ./bin/compozy . である。詳細なフラグ、Linux パッケージ、検証、管理更新は https://compozy.com/docs/getting-started/installation が担う、と README はリンクする。

入れた直後に使うコマンドは Daemon Runtime Model にある。compozy daemon start、compozy status、compozy daemon stop。人とエージェントは公開コントロール面から命令を送り、ホームスコープの daemon がワークスペースを解決し、権限と runtime ポリシーを適用し、ACP エージェントを調整し、イベントとリソース状態を永続化する。Web やストリーミングクライアントは、別モデルを持たず daemon 所有の真実を読む。

構造化出力は -o json。同じリソースを別プログラムから触る面として HTTP/SSE、UDS、MCP、ネイティブツールが列挙される。

パイプして sh に渡す手法は、署名検証が installer 内部で走る前提を信じるかどうかに依存する。README は Sigstore provenance を検証すると書いてある。npm の @beta タグは安定タグではない。ソースビルドは Go ツールチェーンが要る。daemon を start せずに CLI だけ叩いても、セッションは残らない。status が落ちているのに session new だけ成功したように見える状況は、README のモデル（daemon 所有）と矛盾するので、先に daemon start を見る。

~/.compozy/config.toml と AGENT.md の置き場

Config Files 節はグローバル既定を ~/.compozy/config.toml、ワークスペース上書きを .compozy/config.toml とする。明示的なコマンドフラグがワークスペース設定に勝ち、それがグローバルと組み込み既定に勝つ。確認コマンドは compozy config path、compozy config validate、compozy config show -o json。設定、資格情報、provider-home ポリシーは所有者が違うので、v0.2 状態を v0.3 ホームへコピーせず configuration guide を追え、と README は書く。

Reusable Agents は定義を ~/.compozy/agents/<name>/ または .compozy/agents/<name>/ に置く。各定義は AGENT.md を持ち、エージェント局所の mcp.json を付けてよい。ワークスペース定義はグローバル定義を丸ごと上書きする。例示コマンドは compozy agent list -o json、compozy agent info general -o json、compozy session new --agent general。

general というエージェント名は README の例であり、自分の AGENT.md が無い状態で session new が成功するかは、インストール後に list の出力を見てから判断する。

フラグが最優先、という順序を忘れると、ワークスペースの toml を直しても CLI が古い値を使い続ける。config show -o json は、今効いている値を人間が読むための出口である。validate が通らないホームを放置したまま session を量産しない。AGENT.md が無い名前で session new しても、list に出ないエージェントは使えない。mcp.json は任意なので、無いこと自体は欠陥ではない。ワークスペース定義がグローバルを丸ごと上書きする、という規則は、一部キーだけ混ぜるマージではない。

Task Schema v2 は Loops 経由で、tasks run は来ない

著者のタスクファイルは、型付き frontmatter 付きの持ち運び可能な Markdown のままである。v0.3 runtime はそれを durable tasks に取り込み、Loops 経由で実行する。v0.2 の tasks run パイプラインは復活させない。スキーマとコマンドの差分は MIGRATION_GUIDE.md が正本だ。

Extensions は versioned resources と runtime 振る舞いを、宣言した provide surface 経由で足す。daemon が発見、有効化、信頼判断、ライフサイクル、フックを所有し、拡張は公開 runtime 契約を迂回しない、と README は書く。最初の三コマンド例は compozy extension init hello --template tool-provider-go、compozy extension dev hello、compozy tool invoke ext__hello__search --workspace . --input '{"query":"compozy"}'。実行可能拡張はコードでツールを一度宣言し、compozy extension build がマニフェストを生成する。リソースのみの拡張は extension.toml を手書きし、同じ build、dev、reload、watch ループをコード実行なしで使える。

SDK は npm の @compozy/extension-sdk（MIT）と github.com/compozy/compozy/sdk/go が daemon とバージョン対応で公開されている。CLI は extension list、status、provenance、logs --follow。

Markdown のまま持ち運べる、という点は Git でタスク定義をレビューしたい人向けだ。実行エンジンは Loops であり、旧パイプライン名で検索しても v0.3 には無い。hello テンプレの tool invoke は、拡張が公開契約を通っているかを見る最小例である。extension.toml 手書き経路は、コードをコンパイルできない環境向けの逃げ道だ。SDK の npm と Go が daemon とバージョン対応、と書いてあるので、古い SDK で新しい daemon を叩く組み合わせは README が想定していない。

beta を手元で確かめる順序と向かない人

向くのは複数の ACP 互換 CLI を一つの daemon で監督したい個人開発者である。向かないのは v0.2 互換を維持したい本番と、beta 警告を無視して可用性目標を置く組織である。

確認は install.sh または @compozy/cli@beta で、素材の v0.3.0-beta.21 相当を入れる。compozy config validate が異常終了しないこと、compozy session new --agent general が JSON でセッション識別子を返すこと、端末を閉じたあとでも compozy status が daemon を示すこと、をこの順で見る。v0.2 から来る場合は MIGRATION_GUIDE.md の tasks run 削除をチェックリストにし、旧 ~/.compozy を丸ごとコピーせず config validate で差分を見る。

Gateway で遠隔面を開く前に、ローカルの SQLite ストアだけで Loop が残ることを確認する。拡張の hello テンプレは、本番ツールを書く前の契約確認用である。

status で daemon が見えない段階で Gateway を公開面に出さない。ローカルの SQLite で Loop が残ること、session new が JSON を返すこと、config validate が通ること、この三つが揃ってからネットワーク面を足す。v0.2 のホームを zip して展開する移行は、ガイドが禁じる近道である。

編集部の結論

ターミナルを閉じても Loop とセッションを daemon 側に残したい開発者向けである。v0.3 は beta、v0.2.15 からの移行は MIGRATION_GUIDE.md 必須なので、安定版だけ欲しい本番には向かない。curl -fsSL https://compozy.com/install.sh | sh、または npm install -g @compozy/cli@beta のあと compozy daemon start、compozy config validate、compozy session new --agent general が通ることを確認してから、旧 ~/.compozy を丸ごとコピーしない。Homebrew の compozy formula は README が v0.3 安定まで意図的に省略している。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes