[FEATURE]: Persistent session daemon + zero-tool-call memory recall

Feature request: persistent session daemon + zero-tool-call memory recall

• Checkbox: I have searched existing issues for duplicates before creating this request.
• Related / possibly overlapping issues found during search:
  • #23775 — persistent daemon agent for workspace context (overlaps the daemon half)
  • #20695 — Memory Megathread
  • #16077 — Persistent Session Memory
  • #20322 — Native auto-memory for cross-session learning
  • #41338 — subagent continues when interrupted

Context

Two capabilities I haven't found in opencode but which would make long-running, multi-session agent workflows dramatically better. Both are proven in the wild by another open-source Rust terminal agent (jcode, MIT-licensed), which I use as a concrete reference for what to build and why — not as a "copy", but as a proven implementation to learn from.

1. Persistent daemon with server-side session ownership

opencode sessions are per-invocation. When the connection drops mid-turn (SSH, laptop close, TUI kill), the turn dies with it, and there is no server-side session state to resume from.

Ideas to evaluate:

• Optional background daemon (opencode serve) that owns sessions, tools, and provider calls over a socket; the TUI/CLI becomes a client.
• Turns keep executing in the daemon even if the client disconnects; opencode resume picks the session back up.
• Headless login + remote drive (keep the daemon on a homelab/VM, drive from anywhere).

This maps to: every long-running remote/automation workflow, CI-ish agent runs, "let it cook overnight" usage.

2. Memory recall without a tool call (embedded, not token-burning)

Right now memory in opencode goes through MCP tools: the agent must decide to call, spend tokens, and the recall is explicit. jcode instead embeds each turn into a semantic vector at the harness level and on each turn queries its memory graph by cosine similarity, injecting only the relevant hits into context — no tool call, no reasoning budget spent on "should I recall?".

Ideas to evaluate:

• An optional always-on graph store in the daemon (from feature 1) with a configurable similarity threshold.
• Auto-inject matching memories as hidden context; let a side-agent (or nothing) gate relevance.
• Opt-in per-project via config, with a size/importance budget so context stays tight.

The value is qualitative: agents stop "remembering" mid-session because recall is automatic, deterministic, and costs ~0 tokens.

Sync considerations

• Both features are naturally opt-in (a daemon + auto-memory will not suit everyone).
• The daemon makes the memory feature structurally simple; I'd strongly consider them as one initiative.
• Happy to help spec/design if maintainers find either direction worth pursuing.

Environment

• opencode version: latest (as of writing)
• Platform: Linux