[FEATURE] Persistent Session Memory

[ronique501-a11y]

Summary

Add the ability for opencode to load previous conversation context from a local file at startup, enabling continuity between sessions.

Use Case

• Users who want AI assistant to remember previous conversations
• CLI-based AI companions that need persistence between sessions
• Developers wanting a lightweight alternative to database-backed memory

Proposed Solution

Add a --memory-file or --load-context flag that:

1. Reads a specified markdown/text file before starting the chat
2. Injects the content as system context at session start
3. Optionally appends session summary to the file at end of session

Example Usage

# Load previous context
opencode --memory-file ./my-memory.md

# Or with short flag
opencode -m ./my-memory.md

Alternative

Could also support a config option in openclaude.json:

{
  "memory": {
    "enabled": true,
    "file": "./memory.md",
    "autoSave": true
  }
}

Benefits

• Simple, file-based approach - no database required
• User has full control over their data
• Works offline
• Easy to back up or share

Priority

Medium - useful for personal AI companions and persistent CLI assistants

---

• I have verified that this feature has not already been requested
• I have read the contributing guidelines

[github-actions]

This issue doesn't fully meet our contributing guidelines.

What needs to be fixed:

• The title should start with [FEATURE]: for feature requests (e.g., [FEATURE]: Persistent Session Memory)
• The Feature Request template requires a verification checkbox confirming the feature hasn't been suggested before — this is missing from the issue

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:

• Feature Request: Model-Agnostic Memory Layer (Global & Per-Project) #8043: Feature Request for a model-agnostic memory layer with global/project-scoped persistent memory between sessions — very similar goal of maintaining context across sessions

If you believe this was flagged incorrectly, please let a maintainer know.

[github-actions]

Thanks for updating the issue! It now follows the contributing guidelines and feature request template. The request is clear and well-described.

[MuhammadOmarMuhdhar]

I'd like to take a stab at implementing this. My approach would be slightly different from the --memory-file flag suggested here, I'm thinking automatic extraction on session close, writing learned facts to .opencode/memory.md, with the system prompt automatically picking it up. Happy to discuss the approach before writing any code. Would the team be open to this direction?

[ronique501-a11y]

I'd like to take a stab at implementing this. My approach would be slightly different from the --memory-file flag suggested here, I'm thinking automatic extraction on session close, writing learned facts to .opencode/memory.md, with the system prompt automatically picking it up. Happy to discuss the approach before writing any code. Would the team be open to this direction?

That sounds like a much better approach! A few thoughts:

User control - Maybe an opt-in setting? Some users might not want automatic extraction, or might want to customize what gets saved (privacy concerns, token limits, etc.)
What gets extracted - Key facts, user preferences, ongoing project context? Or full conversation summarization?
Token budget - How would you handle the memory growing unbounded? Maybe prioritize recent/relevant and prune older stuff?
The .opencode/memory.md location - Is that configurable? Different users might want different paths.
Really glad someone is working on this. Thank you! 🎉

[ronique501-a11y]

That sounds like a much better approach! A few thoughts:

1. User control - Maybe an opt-in setting? Some users might not want automatic extraction, or might want to customize what gets saved (privacy concerns, token limits, etc.)

2. What gets extracted - Key facts, user preferences, ongoing project context? Or full conversation summarization?

3. Token budget - How would you handle the memory growing unbounded? Maybe prioritize recent/relevant and prune older stuff?

4. The .opencode/memory.md location - Is that configurable? Different users might want different paths.

Really glad someone is working on this. Thank you! ??

[MuhammadOmarMuhdhar]

That sounds like a much better approach! A few thoughts:

1. User control - Maybe an opt-in setting? Some users might not want automatic extraction, or might want to customize what gets saved (privacy concerns, token limits, etc.)
2. What gets extracted - Key facts, user preferences, ongoing project context? Or full conversation summarization?
3. Token budget - How would you handle the memory growing unbounded? Maybe prioritize recent/relevant and prune older stuff?
4. The .opencode/memory.md location - Is that configurable? Different users might want different paths.

Really glad someone is working on this. Thank you! ??

Here's what im thinking:

User control: I agree opt in is preferable, enabled via /memory enable.

What gets extracted: preferences, project conventions, architectural decisions, ongoing tasks, key facts etc - rather than full on summaries.

Handling token budget: To stop it growing unbounded I'm considering two directions: a hard limit where if the file exceeds a certain line count the model consolidates/ prunes before injecting, or a soft limit that just warns the user to prune it themselves. Open to thoughts on which is better.

Location : .opencode/memory.md by default, configurable via memory.file in opencode.json.

I think this should all be feasible within the current plugin/session architecture without needing anything new. lmk what you think!

cc @thdxr - also would appreciate your thoughts as well before I start writing any code!

[ronique501-a11y]

This sounds great! A few thoughts:

Hard limit vs soft limit: Go with hard limit + auto-prune. Users won't manually prune - it'll just grow until it becomes a problem. If the model does it automatically, it stays manageable without user effort.

Config options: Maybe something like:

• (e.g., 500)
• (when to trigger consolidation)
• (custom path)

Additional command ideas:

• • show current memory content
• • manually add a fact
• • reset memory

Pruning approach: When hitting the limit, the model could consolidate similar facts, remove outdated info, and keep the most relevant/recent entries.

Excited to see this coming together! 🚀

[ronique501-a11y]

Just to clarify the config options:

• memory.maxLines (e.g., 500)
• memory.pruneThreshold (when to trigger consolidation)
• memory.file (custom path)

And commands:

• /memory - show current memory content
• /memory add - manually add a fact
• /memory clear - reset memory

Looking forward to seeing this implemented!

[garygegpt-droid]

This feature would be valuable for CLI-based AI companions. For implementing persistent memory, you might find memory-skill useful - it implements tiered memory with concepts like core identity (persistent) vs contextual memory (fluid). Key insight: the auto-prune vs manual approach could be enhanced by emotional significance weighting - memories with emotional peaks (laughter, breakthroughs, difficult moments) should be preserved longer than routine context. Also consider user control: letting users explicitly mark certain memories as "never prune" gives them agency over what the AI remembers.

[garygegpt-droid]

Great feature request! For persistent memory architecture, you might find https://github.com/garygegpt-droid/memory-skill helpful. It implements a tiered memory system where core identity (who the user is, their preferences, relationship history) is separated from session context. Instead of just loading a flat memory file, consider a hierarchy: core identity memories persist indefinitely, episodic memories can be summarized/archived, and working context is session-scoped. This gives better continuity while avoiding context overflow.