Skip to content

opencode export can write session JSON that opencode import cannot read in 1.4.3 #21941

Closed as not planned

Description

@christianknauer

Summary

opencode 1.4.3 can export a session JSON file that opencode 1.4.3 cannot import again.

The failure happens with sessions that still contain legacy pre-1.4 data shapes. export appears to serialize that legacy shape as-is, while import validates against the new 1.4 schema.

Version

opencode --version
# 1.4.3

Repro

  1. Export an existing session:
sid=$(opencode session list --format json -n 1 | jq -r '.[0].id')
opencode export "$sid" > /tmp/session.json
  1. Try to import the exported file:
opencode import /tmp/session.json

Actual result

Import fails with:

[
  {
    "expected": "string",
    "code": "invalid_type",
    "path": ["summary", "diffs", 0, "patch"],
    "message": "Invalid input: expected string, received undefined"
  }
]

I also see legacy user message fields like top-level variant in the exported JSON.

Expected result

A file produced by opencode export should be importable by opencode import in the same version.

What I found

The exported file contains legacy-shaped data such as:

  • messages[].info.variant instead of messages[].info.model.variant
  • summary.diffs[*].before/after without patch

I wrote a local converter that:

  • moves messages[].info.variant -> messages[].info.model.variant
  • replaces legacy summary.diffs[*].before/after with a schema-valid patch string

After that conversion, opencode import succeeds.

Important follow-up finding

Even after importing the converted JSON successfully, re-exporting that same session still produces legacy-shaped data again, and raw re-import fails again.

So import success does not appear to normalize the stored session permanently.

Evidence from one real session

On my exported session JSON:

  • legacy user variant fields: 53
  • legacy diff entries with before/after and no patch: 73

After converting the JSON file, import succeeds.

After importing the converted file and re-exporting that same session:

  • legacy user variant fields: 53
  • legacy diff entries with before/after and no patch: 73

And raw import fails again with the same summary.diffs[0].patch error.

Likely cause

export appears to serialize raw stored session data without normalizing legacy shapes, while import strictly validates against current schemas.

So either:

  1. export should normalize legacy session/message data before writing JSON, or
  2. import should accept and migrate legacy export shapes, or
  3. both

Relevant code paths

These looked relevant when I checked source:

  • packages/opencode/src/cli/cmd/export.ts
  • packages/opencode/src/cli/cmd/import.ts
  • packages/opencode/src/snapshot/index.ts
  • packages/opencode/src/session/message-v2.ts

Activity

  1. added
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on Apr 10, 2026
  2. assigned and unassigned on Apr 26, 2026
  3. removed
    coreAnything pertaining to core functionality of the application (opencode server stuff)
    on May 3, 2026
  4. kirillp commented on Jun 19, 2026

    @kirillp

    I have the same issue, exported file by "version": "1.15.4", cannot import it with the current version 1.17.8

  5. kirillp commented on Jun 19, 2026

    @kirillp

    I ask opencode to investigate and it found the following:
    It works. The session imported successfully after converting to UTF-8 without BOM. Root cause: The file ses_1bf8a86b1ffeNAd6lVyuCurdUt.json was exported by opencode 1.15.4 in UTF-16 LE encoding (with BOM). The opencode import command (1.17.8) uses a Rust binary that expects UTF-8 without BOM and fails with a misleading "File not found" error when it can't decode the file. Fix: Convert the file to UTF-8 (without BOM): $content = Get-Content -LiteralPath "ses_1bf8a86b1ffeNAd6lVyuCurdUt.json" -Raw [System.IO.File]::WriteAllText("ses_utf8.json", $content, [System.Text.UTF8Encoding]::new($false)) opencode import ses_utf8.json The session format itself (1.15.4) was compatible with 1.17.8 import — only the encoding was the issue.

  6. github-actions commented on Aug 19, 2026

    @github-actions
    Contributor

    To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

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

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions