Multi-agent support (Claude Code, Codex, Gemini CLI, Cursor) + possible rename

[EyJunge1]

CC / maintainers

Please weigh in on this product decision:

• Repo owner: @tickernelz
• Maintainers / collaborators with write access: @EyJunge1 @GraDea @NaNomicon @x-Spartacus @amandeavor @lindixu6-hash

---

Related Codex issue

Cross-linking the existing Codex-oriented discussion: #80 (Consider listing in awesome-codex-plugins).

If this decision lands on multi-agent / MCP, that listing (and real Codex support) becomes much more meaningful than an OpenCode-only plugin entry.

---

Problem / motivation

opencode-mem is a strong local memory system (Turso/libSQL vectors, auto-capture, profile learning, web UI), but today it only ships as an OpenCode plugin.

Many users (and potential users) run other coding agents day-to-day:

• Claude Code
• OpenAI Codex CLI
• Gemini CLI
• Cursor (and similar IDE agents)

The memory core (storage, embeddings, HTTP API, web UI) is largely host-agnostic. The interactive parts (hooks, tools, context injection, idle auto-capture) are tightly coupled to OpenCode’s plugin lifecycle.

Question for the community: Should we intentionally become a multi-agent memory product, or stay OpenCode-focused and keep deepening that integration?

This issue is a feature / product decision, not a commitment to ship yet. Please vote and comment with use cases.

---

Proposed direction (if we go multi-agent)

Target hosts (practical priority)

Host	Likely integration	Depth goal (phase 1)
OpenCode	Keep native plugin (current)	Full feature parity (source of truth)
Claude Code	Hooks / skills / MCP	Tools + as much auto-capture as hooks allow
Codex CLI	MCP + hooks	Tools first; hooks where stable
Gemini CLI	MCP	Tools + shared store/UI
Cursor	MCP	Tools + shared store/UI

Architecture sketch

1. Shared core — Turso shards, embeddings, privacy, web UI/API (already mostly reusable)
2. Host adapters — OpenCode plugin stays; add MCP server (+ optional native adapters later)
3. Standalone runtime — ability to run storage + UI without OpenCode starting the plugin
4. Rename / rebrand — so the project clearly signals “memory for coding agents,” not “OpenCode-only”

Rename (open for discussion)

Current name opencode-mem strongly implies OpenCode-only.

Possible directions (examples, not final):

• Keep package opencode-mem + clearer tagline (“works with OpenCode; MCP for other agents”)
• Rename product to something agent-neutral (e.g. agent-mem, codemem, localmem) while keeping OpenCode plugin as first-class
• Dual naming: core package + opencode-mem as the OpenCode adapter

We should not rename lightly (npm, GitHub, configs, docs, muscle memory). If multi-agent is rejected, rename is unnecessary.

---

Pros

• Reach — same memory store across the agents people already use
• Stickiness — memory survives switching OpenCode ↔ Claude Code ↔ Codex ↔ Cursor
• Fits the core — DB/embeddings/UI are already reusable; MCP is the obvious thin adapter
• Future-proof — coding-agent market is fragmented; OpenCode-only caps adoption
• Clearer product story — “local persistent memory for coding agents”

Cons / risks

• Maintenance cost — N hosts, N APIs, N breakage surfaces (hooks differ a lot)
• Feature gap — MCP tools ≠ OpenCode-depth (auto-capture, compaction inject, idle learning may be weaker or missing on some hosts)
• Support burden — “works on Claude but not Cursor” bug reports forever
• Rename pain — npm name, config paths (~/.config/opencode, ~/.opencode-mem), docs, SEO/stars
• Focus dilution — less time polishing the best OpenCode experience
• Expectation management — “multi-agent” can be read as full parity everywhere; we must define phases

---

Alternatives considered

1. Stay OpenCode-only — deepen hooks/v2, ignore other hosts
2. MCP-only expansion — shared tools (search/add/list/profile) + web UI; no deep auto-capture outside OpenCode
3. Full native adapters — Claude/Codex hooks with near-parity (expensive)
4. Document-only interoperability — export/import memories; users glue agents themselves
5. Rename without multi-agent — rejected unless branding alone is the goal (it isn’t)

Recommended default if this decision is accepted: alternative 2 first (MCP + standalone runtime + keep OpenCode native), then evaluate native adapters for Claude Code / Codex based on demand. Rename only after direction is clear.

---

What we want from you

Please react / comment:

1. 👍 — Yes, go multi-agent (MCP-first is fine)
2. ❤️ — Yes, but only if deep auto-capture exists beyond OpenCode
3. 👀 — Interesting, but stay OpenCode-first for now
4. 👎 — No — keep OpenCode-only and don’t rename

Also tell us:

• Which agent(s) you actually use with a memory plugin like this
• Whether shared memory across agents matters to you (same project, different harness)
• Whether a rename would help or confuse you
• Must-have vs nice-to-have: auto-capture, profile learning, compaction restore, web UI only, tools only

Maintainers (@tickernelz @EyJunge1 @GraDea @NaNomicon @x-Spartacus @amandeavor @lindixu6-hash): please leave an explicit +1 / -1 / “need more info” in the thread.

---

Additional context

Today (high level):

• Installed as OpenCode plugin (@opencode-ai/plugin / @opencode/plugin)
• No MCP server, no standalone CLI
• Web UI typically starts from the OpenCode plugin lifecycle
• Config historically lives under OpenCode paths; data under ~/.opencode-mem

This discussion does not mean work has started. If accepted, follow-ups would be separate issues (MCP MVP, standalone server, rename plan, per-host adapters).