今の coding agent にはかなり実務的な管理問題がある。同じ repository でも、今日は Codex、明日は Claude Code、時々 Copilot CLI を試すかもしれない。各 tool は login、terminal、session record、working directory の前提を別々に持つ。失いやすいのは model の返答ではなく、「この session はどの project に属し、何をし、別の tool が引き継げるのか」という boundary だ。

今日見るのは OpenCoven/coven。これは project-scoped coding-agent session の local harness substrate を名乗る。もう一つ chat UI を被せるのではなく、local の Rust daemon が project boundary、cwd validation、PTY lifecycle、event logging、SQLite persistence、IPC enforcement を担い、CLI は convenience layer とする設計だ。README は現在 Codex、Claude Code、GitHub Copilot CLI に focus し、将来の adapter のための contract も用意している。

GitHub repository、README、LICENSE、main branch の Atom commit feed、Releases page を 2026-09-11 18:25 Asia/Shanghai 時点で確認すると、OpenCoven/coven は 47 stars、26 forks。主要言語は Rust、license は MIT。repository は 2026-04-27 05:18:06 UTC に作成され、latest push は 2026-09-11 10:21:57 UTC。最新 main commit は 7928c4e8、時刻は 2026-09-11 10:18:35 UTC、message は chore(deps-dev): bump openclaw to 2026.9.1 (#946)。最新 GitHub Release は v0.4.3、published at は 2026-09-02 21:34:02 UTC だ。Project はまだ pre-1.0 で、README も rough edges を想定するよう明記している。

プロジェクト概要

項目内容
リポジトリOpenCoven/coven
位置づけproject boundary を持つ local coding-agent session runtime
Stars / Forks47 / 26
主要言語Rust
ライセンスMIT
作成日2026-04-27 05:18:06 UTC
Latest push2026-09-11 10:21:57 UTC
最新 commit7928c4e8、chore(deps-dev): bump openclaw to 2026.9.1 (#946)
最新 Releasev0.4.3、2026-09-02 21:34:02 UTC
Install の入口npm install -g @opencoven/cli
主な対象Codex、Claude Code、GitHub Copilot CLI

Model を揃えるより、session の ownership を揃える

多くの agent launcher は model の切り替えを楽にする。Coven の面白い選択は、「誰が session constraint を持つか」を先に置くことだ。README は明確に、harness はユーザーが選び、session は Coven が持つと書く。Rust daemon は authority boundary であり、security decision は daemon に向かって収束し、上位 client が逆向きに決めることはできない。

これは日常の development machine では意味がある。たとえば Codex に test の修正をさせ、その後 Claude Code に review を頼むとき、大切なのは同じ dashboard に見えることではない。起動 cwd、project identity、PTY lifecycle、persisted record が同じ local authority を持つことだ。agent を替えても、「前の作業はどの repo で何をしたのか」を新しい tool に推測させずに済む。

まず local daemon に一つの session を任せる

README の基本 path は慎重だ。@opencoven/cli を global install し、project directory に入る。coven setup codex で provider 自身の login を完了させ、coven doctor で local readiness を確認し、coven daemon start を実行する。その後 coven run codex "fix the failing tests" で session を起動する。coven sessions で session を見て管理し、終われば daemon を停止できる。

ここで残される boundary は大事だ。login は provider の責任であり、Coven が account や key を引き取ると主張しているわけではない。すでに動く harness を一つの local project lifecycle に置く。それは複数の agent CLI をすでに使う人にとって、「もう一つの Web service の URL」を覚えるより実際の作業に近い。

SQLite と memory dashboard は検査可能性を増やすが、data の責任も増やす

Project は event logging と SQLite persistence を core に置き、memory dashboard は別 install の optional companion にしている。これにより session は terminal や tool をまたいで残り、troubleshooting や引き継ぎも流れ去る terminal buffer だけに頼らなくなる。ただし「たくさん記録すれば安全」ではない。

README の security note は具体的だ。session log は harness output を捕捉する。API display 前に event payload を redaction しても、secret が prompt や output に出てはいけない。また sensitive repository では untrusted な harness や prompt を動かさないよう勧めている。local-first が解決するのは control の置き場所であり、log、permission、third-party agent の risk を自動で消すものではない。

どこから試すべきか

向くのは二種類だ。一つは、一台の machine で複数 repo を行き来し、Codex、Claude Code、Copilot CLI を使い分ける developer。まず non-sensitive project で doctor、daemon、session list が context handoff を本当に改善するか確認したい。もう一つは internal agent workflow を作る team だ。独自の security constraint を UI button の奥に隠すのでなく、harness adapter contract と daemon authority model を検討できる。

最初から multi-user collaboration platform、secret vault、agent sandbox と見なしてはいけない。まだ 1.0 前であり、Linux distribution や runtime environment は official install docs で確認が必要だ。session manager が整っていても、agent がアクセスできる file、command、network permission は project と system level で別に制約する必要がある。

まとめ

Coven の niche な価値は、新しい agent を発明するのでなく、既存 agent CLI に ownership の明確な local project session を与える点にある。複数 coding harness がそれぞれ半端な context を残し、project boundary と lifecycle が揃わないことが痛みなら、この Rust daemon + CLI の方向は安全な試験 repository で一度動かす価値がある。

プロジェクト: https://github.com/OpenCoven/coven