Coven
A local-first runtime substrate that lets Codex, Claude Code, and GitHub Copilot CLI agent sessions run visibly and safely inside explicit project boundaries.
- Source repo
- OpenCoven/coven
- Stars
- ★ 65
- Last updated
- today
- License
- MIT
- Primary language
- Rust
- FA score
- 79/100 · Good
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · Claude CodeChatGPT (Partial support)
- Cost
- Free, no paid service needed
- Setup effort
- Low · running in minutes
- You'll need
- Typical use
- A developer switching between Codex, Claude Code, and GitHub Copilot CLI in one repository wants session history, event logs, and state managed locally by one daemon.
- Not a fit if
- Teams needing a mature, stable 1.0 tool — Coven is an early MVP with documented rough edges
- Users running untrusted prompts in repositories with sensitive secrets, since session logs may capture them
- Users on Alpine Linux or other non-glibc x64 environments
- Source review
- 79/100 · Good
What does this agent do, and when should you use it?
Coven is the local harness substrate of the OpenCoven ecosystem, giving coding-agent CLIs like Codex, Claude Code, and GitHub Copilot CLI a shared room for project-scoped work. A Rust daemon is the authority boundary: session launch, cwd validation, PTY execution, event logging, and SQLite persistence all live in the daemon, while the CLI, TUI, and other clients are convenience layers — security decisions flow inward to the daemon, never outward. The architecture is local-first: state is persisted on-machine in SQLite and exposed via a same-user local IPC API defined by the coven.daemon.v1 contract. It ships as the npm package @opencoven/cli with support for macOS, Linux x64 (glibc), and Windows x64. It is an MIT-licensed early MVP in active development, with canonical documentation at docs.opencoven.ai.
Coven's concrete operations center on project-scoped agent sessions: coven setup codex completes the provider-owned login, coven doctor checks local readiness, and coven daemon start launches the Rust daemon that handles cwd validation, PTY lifecycle, event logging, and SQLite persistence. coven run codex "fix the failing tests" launches a Codex session inside the project boundary; coven sessions browses and manages session history; coven daemon stop halts the daemon. Supported harnesses are Codex, Claude Code, and GitHub Copilot CLI, with an adapter contract (docs/HARNESS-ADAPTERS.md) for future expansion. All clients — the CLI/TUI, CastCodes, comux, or your own integration — access the same session state through the same-user local IPC API (coven.daemon.v1). An optional memory dashboard installs separately as @opencoven/coven-memory-dashboard. Running bare coven opens the interactive UI.
- A developer switching between Codex, Claude Code, and GitHub Copilot CLI in one repository wants session history, event logs, and state managed locally by one daemon.
- A team that needs to audit what agents did in a project: Coven records PTY execution and events, browsable via coven sessions.
- A tooling author building their own interface can integrate over the same-user local IPC API (coven.daemon.v1 contract) instead of reimplementing the execution layer.
- Security-conscious users want cwd validation, PTY lifecycle, and IPC enforcement decided centrally by a Rust daemon rather than by clients.
- An adapter author can implement and plug in a new coding-agent CLI following the harness adapter contract in docs/HARNESS-ADAPTERS.md.
How do you install or deploy this agent?
Install via npm (the universal wrapper auto-selects your platform package), then run the self-check:
bash
npm install -g @opencoven/cli
coven doctorPlatform packages: @opencoven/cli-macos (Apple Silicon), @opencoven/cli-macos-x64 (Intel), @opencoven/cli-linux-x64 (glibc x64, Alpine unsupported), @opencoven/cli-windows (Windows x64). The optional memory dashboard requires Node.js 24+ and installs separately:
bash
npm install -g @opencoven/coven-memory-dashboardnpm, cargo, and source install routes are documented at https://docs.opencoven.ai/docs/guide/install. Harness logins are provider-owned (e.g. coven setup codex for Codex).
How do you use this agent?
Complete one full flow inside your target project directory:
bash
cd /path/to/your/project
coven setup codex
coven doctor
coven daemon start
coven run codex "fix the failing tests"
coven sessions
coven daemon stopRunning bare coven opens the interactive UI. The CLI command reference is at https://docs.opencoven.ai/docs/cli. For contributors: run python scripts/check-secrets.py before every PR and never commit runtime state (.coven/, *.sqlite*, *.sock, .env*, *.key).
What are this agent's strengths and limitations?
- Multi-harness neutrality: Codex, Claude Code, and GitHub Copilot CLI all run inside one project boundary, avoiding lock-in to a single vendor's agent.
- The Rust daemon is the sole authority boundary — cwd validation, PTY, and IPC decisions are architecturally separated from clients.
- Local-first: session state persists to on-machine SQLite with auditable event logs and a documented IPC contract (coven.daemon.v1) for third-party integrations.
- MIT licensed, external PRs open, distributed across macOS/Linux/Windows x64.
- Early MVP — the README says it is usable for adventurous developers but expects rough edges, so it is not a conservative production choice yet.
- Session logs capture harness output; if a harness dumps secrets, Coven logs them — the project advises against untrusted prompts in sensitive repositories.
- Linux distribution is glibc x64 only (no Alpine), and the memory dashboard additionally requires Node.js 24+ and a separate install.
- Until adapter contracts stabilize, harness support is deliberately limited to Codex, Claude Code, and GitHub Copilot CLI.
How does this agent compare with similar options?
Coven positions itself explicitly as a shared runtime substrate beneath coding-agent CLIs like Codex, Claude Code, and GitHub Copilot CLI: those tools each own their session and permission models, while Coven adds a unified session lifecycle, SQLite persistence, and an authoritative daemon so any harness's work is visible and coordinated within the same project.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| Coven This agent | 79 · Good | CLIFree | ★ 65 | today | Rust | Codex · Claude Code |
| Puppetmaster | 68 · Some gaps | CLIFree + model costs | ★ 457 | 1d ago | Python | Codex · Claude Code |
| Cezar — AI Coding Agent Orchestrator | 63 · Some gaps | CLIFree | ★ 464 | 2d ago | TypeScript | Codex · Claude Code |
| OpenTeams | 56 · Major gaps | Desktop appFree + model costs | ★ 626 | 13d ago | TypeScript | Codex · Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows an unusually explicit security model: the Rust daemon as sole authority boundary, argv-only launch (never sh -c), canonicalized paths, fail-closed validation, event redaction before storage, raw artifacts opt-in and encrypted, same-user local IPC only. Deductions: the daemon explicitly does not sandbox running harnesses (user-privilege execution); COVEN_HOME ownership/permission checks are self-declared as an unhardened gap; the raw-artifact key is a local file, not OS keychain; rollback evidence is limited to retention/pruning with no recovery path for agent-made changes, so rollback scores 1. least_privilege capped at 2 due to absent sandboxing.
Self-consistency is strong: security policy, API contract, session state machine, and adapter contract each map to named test families exercised in CI (rust-test, threads, AFS, conformance jobs). Dependency availability covers a three-platform matrix with Alpine explicitly unsupported; builds use --locked and Cargo.lock. Failure messages are test-evidenced (precise, non-leaking rejection messages in the channels package), but only small TypeScript samples are visible; the main CLI error surface is not shown, scoring 2.
Audience and scenarios are honestly scoped (early MVP, adventurous developers, platform matrix, external install/container docs); capability boundaries are the project's strongest area — SECURITY.md enumerates what is NOT provided (no cross-user isolation, no A2A isolation, remote listener unshipped); environment fit is granular (per-platform npm wrappers, Apple Silicon/Intel split). Deduction: trigger/command behavior relies heavily on the external docs site; in-repo evidence for trigger precision is limited, scoring 2.
Information architecture is clear: the repo keeps only source-adjacent normative docs with stated reasons and points the rest at the docs site; install notes include the platform wrapper table and `coven doctor`; known-limitations disclosure is unusually thorough (retention is not secure deletion, historical commits predate privacy rules, no remediation deadlines); LICENSE is complete and Cargo.toml declares MIT consistently. Deductions: no CHANGELOG file and version semantics only referenced via releases (v0.4.x); maintenance responsibility rests on a single named author with explicitly no response-time commitment; examples are quick-start only with FAQ/troubleshooting mostly off-repo, each capped at 2.
Output usability has plausible evidence (session browsing, event API, opt-in memory dashboard) but nothing is execution-verified; marginal value lies in unifying multiple harnesses (Codex/Claude Code/Copilot CLI) under a project-scoped session substrate — a real gap, though pre-1.0; cost/benefit is reasonable (Rust daemon + npm wrappers; benchmarks use disposable COVEN_HOME). All three score 2: the design is sound but this static review cannot confirm realized benefit.
Fact/inference separation is exemplary: SECURITY.md sections 2/5 explicitly separate 'enforced today' from 'design goals' and state that SLOs are not security properties; every claim is tied to a normative contract and verification family (claim_traceability 3). Deductions: cross-source corroboration relies on in-repo self-reference plus the external docs site, and the key referenced contract documents (SAFETY-MODEL, API-CONTRACT) are not present in the provided evidence, scoring 2; enforced-property claims cannot be executed in static review and were not allowed to inflate neighbors.
- Coven explicitly does not sandbox harnesses: a hostile prompt or harness output can act with full user privileges; never run untrusted harnesses or prompts in sensitive repositories.
- Do not paste secrets into prompts; event payloads are redacted, but if a harness dumps environment variables, secrets land in session logs.
- COVEN_HOME ownership/permission checks are a declared hardening gap; do not treat the boundary as complete against other local processes.
- Raw artifact persistence (persist_raw_artifacts=true) is encrypted but keyed by a local file, unsuitable for shared or higher-risk machines.
- Pre-1.0 with no remediation-deadline commitment; track releases yourself and prepare a fast rollback plan for production use.
- The AgentFS mount backend is experimental: loopback-only, single-user, not durable storage, never expose beyond localhost.
- Publisher is unverified (not in the curated enterprise registry); treat identity as unknown and independently verify npm package integrity and checksums.