Skip to content

[Bug] Runtime repair passes only transcript tail — full session history is dropped from new context #104

Closed as not planned

Description

@nleononline

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

  1. Run an ongoing session with significant context.
  2. Trigger a runtime repair (daemon restart, OpenCode crash, long idle, etc.).
  3. 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.

Activity

  1. added
    bugSomething isn't working
    desktopMiniMax Code desktop app
    needs-triageAwaiting maintainer assessment
    and removed
    desktopMiniMax Code desktop app
    on Sep 19, 2026
  2. hetaoBackend commented on Sep 21, 2026

    @hetaoBackend
    Collaborator

    This was generated by AI during triage.

    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.

  3. hetaoBackend commented on Oct 19, 2026

    @hetaoBackend
    Collaborator

    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。感谢反馈!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingdesktopMiniMax Code desktop appneeds-triageAwaiting maintainer assessment

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions