Summary
When MiniMax Code repairs a session (after daemon restart, idle timeout, OOM, or mode switch), the new runtime receives only the last ~4 messages in its <visible-transcript> block. The full conversation history exists on disk but is not loaded into the new context — the model loses awareness of the original task, scope, and prior decisions, and may believe it never received the task at all.
This is not an LLM-summarization failure. The summarization mechanism (session_context_epoch) exists but is never triggered, because the repair path bypasses it entirely.
Environment
- MiniMax Code (Electron) on macOS
- Observed session at time of repair: 513 messages, 2.2 MB on disk
- OpenCode DB:
~/.local/share/opencode/opencode.db
- Mavis DB:
~/.mavis/sqlite.db
Reproduction
- Run an ongoing session with significant context.
- Trigger a runtime repair (daemon restart, OpenCode crash, long idle, etc.).
- Inspect the
<visible-transcript> block delivered to the new session.
Expected
The repaired session reconstructs full context — either by injecting the complete session_messages history, by running session_context_epoch summarization, or by restoring from $MAVIS_SCRATCHPAD.
Actual
Only the last ~4 messages are passed. No summary, no history injection, no scratchpad restore.
Findings
~/.mavis/sqlite.db.session_messages retains the complete history (513 messages / 2.2 MB in the observed case). The data is on disk — it's just not loaded.~/.local/share/opencode/opencode.db.session_context_epoch exists with a proper schema for LLM summarization (baseline, snapshot, baseline_seq, replacement_seq), but the table is empty — the mechanism never ran in observed sessions.- The session was far below the LLM-context limit, so summarization was never triggered organically either.
- Conclusion: "context loss after repair" is the repair path skipping both summary and history-injection. Not a token-limit issue, not an LLM-summary quality issue.
Summary
When MiniMax Code repairs a session (after daemon restart, idle timeout, OOM, or mode switch), the new runtime receives only the last ~4 messages in its
<visible-transcript>block. The full conversation history exists on disk but is not loaded into the new context — the model loses awareness of the original task, scope, and prior decisions, and may believe it never received the task at all.This is not an LLM-summarization failure. The summarization mechanism (
session_context_epoch) exists but is never triggered, because the repair path bypasses it entirely.Environment
~/.local/share/opencode/opencode.db~/.mavis/sqlite.dbReproduction
<visible-transcript>block delivered to the new session.Expected
The repaired session reconstructs full context — either by injecting the complete
session_messageshistory, by runningsession_context_epochsummarization, or by restoring from$MAVIS_SCRATCHPAD.Actual
Only the last ~4 messages are passed. No summary, no history injection, no scratchpad restore.
Findings
~/.mavis/sqlite.db.session_messagesretains the complete history (513 messages / 2.2 MB in the observed case). The data is on disk — it's just not loaded.~/.local/share/opencode/opencode.db.session_context_epochexists with a proper schema for LLM summarization (baseline,snapshot,baseline_seq,replacement_seq), but the table is empty — the mechanism never ran in observed sessions.