Repository navigation
[FEATURE]: Persistent session daemon + zero-tool-call memory recall #41453
Description
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:
- [FEATURE]: persistent daemon agent for workspace context with push/pull coordination #23775 — persistent daemon agent for workspace context (overlaps the daemon half)
- Memory Megathread #20695 — Memory Megathread
- [FEATURE] Persistent Session Memory #16077 — Persistent Session Memory
- [FEATURE]: Native auto-memory for cross-session learning #20322 — Native auto-memory for cross-session learning
- [FEATURE]: Add a way to make a subagent continue to work that's interrupted for some reason like internet or closed opencode or computer shutdown. #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 resumepicks 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
Activity
github-actions commentedon Aug 9, 2026
This issue doesn't fully meet our contributing guidelines.
What needs to be fixed:
[FEATURE]: Persistent session daemon + zero-tool-call memory recall)Please edit this issue to address the above within 2 hours, or it will be automatically closed.
This issue might be a duplicate of existing issues. Please check:
If you believe this was flagged incorrectly, please let a maintainer know.
iwanro commentedon Aug 9, 2026
Additional feature candidates (follow-up to the request above)
Same framing as before — learned from how other open-source terminals agents handle these. All four are additive and don't require the daemon to ship first.
A. Native multi-agent coordination with conflict notification
Right now spawning parallel agents works, but there is no coordination layer: two agents working the same repo silently race on file edits. The useful model to evaluate:
swarmtool that lets the active agent spawn its own teammates and turn itself into a coordinator, with group state (channels, completion) managed automatically — headless and headed.Value: parallel work becomes safe instead of "hope the edits don't collide".
B. Side panel + inline diagram rendering
A side panel for auxiliary state that's not in the transcript — load a file into it, write to it directly, or use it as a live diff viewer while the main turn runs. Include inline rendering of mermaid diagrams in the transcript (a non-browser renderer would keep startup lean).
Value: observable long-running turns without spamming the transcript or reading files manually.
C.
/transferand session search/transfer: compact the current context into a fresh handoff session with a summary, instead of just continuing longer in the same one — a first-class way to keep long tasks healthy.Value: escapes the "context is filling up again" cycle; turns old learnings into a searchable asset.
D. Full headless OAuth for all providers
The common flows measured (Claude, OpenAI, Gemini, Copilot) currently expect a browser. For servers, homelabs, and CI, the pattern to support:
--no-browserprints an auth URL; a two-step flow (--print-auth-urlnow, then--callback-url/--auth-codelater) completes the exchange without a display, andauth-testvalidates whatever is configured.Value: remote/daemon usage (and feature #1 above) is only realistic once auth works without a display.
[-]Persistent session daemon + zero-tool-call memory recall[/-][+][FEATURE]: Persistent session daemon + zero-tool-call memory recall[/+]github-actions commentedon Aug 9, 2026
Thanks for updating the issue! Everything looks good now — the
[FEATURE]:prefix and the duplicate-search checkbox are both in place. We appreciate you taking the time to follow up.github-actions commentedon Oct 10, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.