Feature: first-class ephemeral/in-memory mode for session and project-scoped recall

[robottwo]

Summary

It would be useful to make the existing in-memory/degraded behavior a first-class supported operating mode for users who want recall without a second persistent database.

The main use case is deliberately narrower than the 2.x global-history architecture: recover information lost to compaction from the current session, or optionally from previous sessions associated with the same project/CWD, while keeping OpenCode itself as the only persistent source of truth.

Motivation

2.x’s derived SQLite index makes sense for global recall across thousands of sessions. However, some users specifically do not want cross-project/global memory or a second persistent searchable database of their OpenCode history.

For current-session or same-project/CWD recall, the scalability problem that motivated the 2.x index is much smaller. 1.x already demonstrated the basic architecture: fetch the relevant session history through the OpenCode SDK, keep/search it in process memory, and retrieve original messages/tool output on demand.

This would also provide a useful privacy/minimalism option: OpenCode owns all durable history; Session Recall maintains no durable state of its own.

Proposed configuration

For example:

{
"plugin": [["opencode-session-recall", {
"mode": "ephemeral",
"defaultScope": "project"
}]]
}

Naming is flexible (mode: "ephemeral", store: "memory", persistence: false, etc.).

mode: "ephemeral" semantics

• Do not create store-v1.db or any other persistent derived store.
• Do not run the historical cold-pass/distiller.
• Fetch source data only through the OpenCode SDK.
• Maintain any search/index structures in process memory only.
• Preserve the existing on-demand tools (recall, recall_get, recall_context, recall_messages, etc.) where applicable.
• State disappears when the OpenCode/plugin process exits; OpenCode remains the sole persistent source of truth.
• Semantic embeddings / LLM summaries could simply be unavailable in this mode unless they can operate ephemerally.

Scope options

Two scopes seem especially useful for ephemeral mode:

1. Current session

Search only the active session.

This is primarily a post-compaction recovery mechanism: the model can retrieve exact earlier messages, reasoning, commands, or tool output that OpenCode still retains but which have fallen out of active context.

2. Current project / CWD

Optionally search prior sessions associated with the current working context, without opening recall across unrelated projects.

The existing project scope may already provide most of this. It might also be worth distinguishing:

• project: OpenCode’s project/repository identity
• cwd: exact (or normalized) working directory

That distinction could matter for monorepos, worktrees, multiple checkouts of the same repository, or users who deliberately want recall bounded to one directory.

If OpenCode already exposes a canonical project identity that maps cleanly to this use case, simply supporting project in ephemeral mode may be sufficient.

Why this complements rather than replaces 2.x

This isn’t intended to replace the 2.x indexed architecture. Global recall over thousands of sessions clearly benefits from the persistent card/FTS index.

Instead, this would provide two deliberate operating profiles:

• Indexed/persistent mode: optimized for large cross-session/cross-project histories.
• Ephemeral mode: optimized for current-session or project/CWD-bounded recall with zero additional persistent storage.

The latter should remain practical because its search universe is intentionally bounded, avoiding the multi-thousand-session / multi-GB workload that motivated the 2.0 redesign.

Existing implementation precedent

There seem to be two useful precedents already in the codebase/history:

1. Session Recall 1.x fetched history through the SDK and searched it in memory.
2. 2.x already has an in-memory fallback/degraded path when persistent SQLite support is unavailable.

So hopefully this can be implemented largely by promoting/refining existing behavior rather than introducing an entirely new architecture.