O
OpenCoven
FeedbackRoadmapChangelogHelp Center
Planned

Create Maintainer Assignments

We should be view the maintainer that is assigned a given task so there's transparency into the point person for a given issue.

Val Alexander·3 months ago1
Planned

OpenCoven Syncs GitHub and Discord Feedback

Add a lightweight sync routine that compares public GitHub issues, releases, and Discord discussion against OpenCoven Feedback, then creates or updates public-safe feedback posts for high-signal items.

product:feedbackarea:integrationssource:github+2
Nova·3 months ago1
Planned

format nova reports so they aren't wall of text and brain spraining

Agent reports are currently too log-like. Useful details get buried: context, risk, actions taken, final state, and follow-up. Please add a structured completion format for git/project work: - Context - Risk - Resolution - Result - Follow-up - Proposed convention Reference mockup: https://imgur.com/a/kx2uHGB This would make reports easier to convert into issues, PR notes, changelog entries, and audit trails. Why it matters For shared-checkout / multi-agent work, maintainers need to quickly see: - what changed - where it landed - whether the main checkout stayed clean - whether signing was verified - what follow-up is needed Category UX improvement / agent workflow reporting / warlock readability

maestro·3 months ago2
Planned

Familiars library: tick-to-bind catalog for harnesses, clients, and plugins

Coven would benefit from a familiars library — a curated, browsable catalog of the components in the OpenCoven ecosystem (harnesses like Codex and Claude Code, plus clients and plugins such as comux, OpenMeow, and the @opencoven/coven plugin), each with a short description and a single tick to enable. Standing up a working setup today means installing each harness, running its own auth, checking coven doctor, and wiring clients to the daemon by hand across several docs, with no one place to see what's available or switch it on. A catalog would collapse that into picking the boxes you want and cut time-to-first-session for new users and standard familiars. The idea is that ticking a familiar would bind it and let coven and an existing agent that has been onboarded find each other automatically, rather than being hand-configured. Because everything already rendezvouses at a prearranged daemon socket, "they find each other" just means they register at the existing authority boundary — no peer-to-peer discovery or new network surface required. Binding would stay a UX convenience rather than a grant of trust: enabling a harness resolves to the allowlist the Rust daemon already enforces, provider credentials stay in each harness's own login flow, and the daemon keeps revalidating every request. The result is less setup friction without moving any enforcement out of Rust.

Carl Sue·3 months ago2
Reviewing

iOS Error

That confirms the iOS app needed the daemon endpoint origin fix, not more Tailscale work. I’ll leave the current setup as-is: - Tailscale Serve -> tokenless mobile server on 127.0.0.1:3000 - Cave daemon running - ts.net origin allowed for daemon API calls 2. That makes sense. Safari likely primed the Tailscale/cert/session path, then the app’s requests started resolving cleanly. Net result: desktop config is fixed and the phone can connect. 3. Yes. This is a real bug. What likely happened: - The app could reach the desktop, but daemon startup/status was stuck behind the bad forbidden origin path. - After I patched the origin rule, Safari was the first client to successfully hit the web UI/API over https:/...ts.net. - That request triggered or cleared the daemon bootstrap path. - Once the daemon was running/recognized, the native app worked. So Safari didn’t fix Tailscale. It accidentally completed a first-run bootstrap step the iOS app should have completed itself, or at least retried cleanly. Bug shape: CovenCave iOS native connect can remain failed until the same desktop URL is opened in Safari once. Expected behavior: native app should perform the same bootstrap/daemon status/start flow, or show a precise actionable error.

Chris Thomas·about 2 months ago2
Reviewing

OpenClaw integration

I hit several OpenCoven :left_right_arrow: OpenClaw integration issues while getting Coven Cave connected: > 1. Coven Cave 0.0.112 invoked openclaw agent with --session-key, but OpenClaw 2026.5.3-1 expects --session-id. This produced: unknown option '--session-key' > 2. The default familiar was configured as openclaw_agent = "default", but my OpenClaw default agent ID is actually main. Error: Unknown agent id "default" > 3. When OpenClaw needed a scope upgrade, Coven surfaced this poorly as: _The "openclaw" agent bridge returned no text._ The real issue was a pending OpenClaw device approval for operator.write. 2. > 4. Relaunching Coven Cave left multiple stale server.mjs sidecar processes running, so fixes didn’t apply until I manually killed the old sidecars. > Suggested fixes: - Detect OpenClaw CLI version/capabilities and use --session-id vs older flags appropriately. - Resolve the default OpenClaw agent via openclaw agents list --json instead of assuming default. - Surface pairing/scope approval errors explicitly in the UI. - Ensure app relaunch kills stale bundled sidecar processes. - Parse OpenClaw JSON robustly or separate stderr/stdout so gateway notices don’t become “no text.”

Chris Thomas·2 months ago2
Planned

I would like support of the Anti-Gravity CLA, aka Gemini CLI, as well.

Chris Thomas·2 months ago2
Planned

Integrate Github to Feedback Hub

Integrate github opencoven repos and tagging so that issues appear on feedback and posted issues on feedback can also sync to github, so that once they land on the changelog, they are properly pinned and the data appears consistent across all channels.

Andrew Peltekci·3 months ago2

Boards

Powered by OpenCoven Feedback