You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug] Runtime repair passes only transcript tail — full session history is dropped from new context #104
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.
Excellent analysis — the distinction you draw (repair path bypasses session_context_epoch summarization entirely, rather than summarization failing) matches how a tail-only transcript would present.
Agreed this is a bug: repair should route through the same context-restoration path as normal resume, not a raw ~4-message tail. Note the runtime's session-restore path has been significantly reworked in the v2 runtime; we'll verify whether the bypass persists there and fix accordingly. Tracked.
Closing as part of a backlog cleanup: this issue was filed more than a month ago against an older release, and the codebase has changed substantially since then. If it still reproduces on the latest version, please open a new issue with the current version and reproduction steps. Thank you for the report!
Activity
hetaoBackend commentedon Sep 21, 2026
Excellent analysis — the distinction you draw (repair path bypasses
session_context_epochsummarization entirely, rather than summarization failing) matches how a tail-only transcript would present.Agreed this is a bug: repair should route through the same context-restoration path as normal resume, not a raw ~4-message tail. Note the runtime's session-restore path has been significantly reworked in the v2 runtime; we'll verify whether the bypass persists there and fix accordingly. Tracked.
hetaoBackend commentedon Oct 19, 2026
Closing as part of a backlog cleanup: this issue was filed more than a month ago against an older release, and the codebase has changed substantially since then. If it still reproduces on the latest version, please open a new issue with the current version and reproduction steps. Thank you for the report!
批量清理积压:该 issue 创建已超过一个月,针对的是较旧版本,代码已有较大变化。如果在最新版本上仍能复现,欢迎附上当前版本号和复现步骤重新提交 issue。感谢反馈!