RSS Feed Doesn't Show Most Recent Updates.

https://feedback.opencoven.ai/changelog

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

The AppImage is not starting

The AppImage is not starting

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.

Browser Extensions

Mac OS: Cannot Remove Familiars

I set up a familiar based on thinking I was selecting the correct one for an OpenClaw agent that had multiple instances. It turns out it wasn't and I would like to remove the familiar from the list. I see the ability to archive it but I do not see the ability to remove it.

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.”

Add a Vector-Backed Semantic Memory Layer for Familiars

OpenCoven already has a strong local runtime foundation: project-scoped sessions, familiar identity, tool access, PTY supervision, event logs, and SQLite-backed persistence. A valuable next layer would be an optional semantic memory backend for familiars. Suggested architecture: - Keep SQLite as the authoritative local store for sessions, events, logs, project metadata, and familiar records. - Add a sidecar “memory vault” service for semantic retrieval. - Support endpoints such as /query, /learn, /upload, /stats, and /health. - Store chunked memories, embeddings, tags, source metadata, and uploaded documents. - Let familiars query this memory before acting, so they can retrieve relevant prior decisions, project context, docs, user preferences, and historical work. - Keep it local-first by default, but allow network-visible deployment over private networks like Tailscale for trusted multi-agent/team setups. This would make OpenCoven’s persistent agents feel much more durable: not just resumable sessions, but familiars with long-term, searchable institutional memory. 2. In short: OpenCoven already has the identity/runtime layer. A vector-backed semantic memory layer would give it a powerful long-term knowledge layer.

Add a tie-in for a Knowledge Vault separate from memory systems so that it can be used across all harnesses.

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

In Terminal, once the model is set, switching models becomes impossible even after starting a new session.

Select Model 1. open new terminal session 2. type "coven-code" 3. type "/model" to change model 4. select model 5. exit out Try to select different model 1. open new terminal session 2. type "coven-code" 3. type "/model" to change model 4. attempt to select different model

CovenCave v0.0.59 | Library Filter Row Can Feel Clipped On Default Desktop Window

Impacted sections: - Library > Timeline - Library > Projects Context: The Library page in CovenCave 0.0.59 rendered visibly and looked much improved overall. At the tested desktop window size, though, the right-side Library search/filter strip looked horizontally cramped: the search field appeared partially clipped and the All lists control sat at the window edge.

CovenCave v0.0.59 | Search modal blocked by Browser

When on the "Browser" tab and then clicking the search bar in header, the browser window blocks the search modal, preventing use. Workaround: - Just clicking into another section/tab, I can then interact with the search modal.