Coven’s safety model rests on four invariants:Documentation Index
Fetch the complete documentation index at: https://docs.opencoven.ai/llms.txt
Use this file to discover all available pages before exploring further.
- The Rust daemon is the only authority. Clients can ask; only the daemon decides whether to spawn a PTY, canonicalize a path, or mutate the ledger.
- The socket is same-user local trust. No daemon OAuth, JWTs, bearer tokens, API keys, or browser cookies.
- Coven never stores provider credentials. Each harness keeps using its own login.
- Destructive operations are explicit. Sacrifice refuses live sessions and requires
--yes. Relief verbs incoven pcrequire--confirm.
Trust boundary
Anyone able to read/write<covenHome>/coven.sock has full local access. Coven assumes filesystem permissions enforce that boundary.
What Coven validates
- Project root. Must be explicit, absolute, and canonicalize to itself.
- Working directory. Must canonicalize inside the project root.
- Harness id. Must match an allowlisted adapter.
- Live input. Forwarded only to running sessions you own.
- Kill requests. Refused if the session is not live.
- Session ids. Validated as ULIDs the daemon issued.
Secret handling
- Coven does not read provider API keys.
- Coven does not log harness stdout containing user data unless the operator opts in.
- Diagnostics bundles redact known secret-shaped tokens by default. See Diagnostics bundle.
- Runtime state under
$COVEN_HOMEmust not be committed to source control.
Remote access
Coven does not bind a TCP port by default. If you need a remote daemon, tunnel the Unix socket — see Remote access. Tailscale and SSH local-forwards both work.Automation approvals
Coven’s destructive operations require explicit confirmation:coven sacrifice <id> --yes— permanent delete.coven pc relief --confirm— kill processes or clear caches.coven patch openclaw— never commits or pushes in v0.