Bringing another tool's old conversations into DSH: where the formats differ

When to use

Switched tools and want to bring hundreds of old conversations along. The instinct is that both are JSONL, so a rename should work. It does not.

Preparation

Host version

To fill (record the exact rc version when testing)

Model

To fill

Mode / permissions

Standard mode + modify-within-workspace is enough to start

Plugins required

None (add name & version after testing if used)

Input materials

Keep in a separate workspace; back up originals first

Full instruction

I want to migrate another tool's old conversations into DSH. First confirm the storage facts on the DSH side, then discuss migration.

1. Where are DSH sessions stored? Give the full path rule, including how a workspace path is escaped into a directory name.
2. Is one session one file or several? What compression format?
3. What is the structure of the first line? And of each subsequent line (which field is the sequence, which is the timestamp)?
4. List event types you can confirm exist, and say which are streaming increments (chunks) and which are complete messages.
5. Given all that, state three things about migrating another tool's conversations: what maps directly, what must be synthesised, and what is inevitably lost.

Requirements:
- Every fact cites its basis (doc section, package source path, or measurement). Mark impressions as inferred.
- Do not write 'session formats are usually JSONL so it just works'. If the compression or event vocabulary blocks direct reuse, say so plainly.
- Give me a command that verifies whether a session file is valid, decidable without reading its content.

End with a feasibility table: data item | migratable | what is needed | risk.

Copy full instruction

Run log

Output

After a successful run, list files and screenshots here, and note whether originals changed.

Acceptance checklist

Tap to tick each item off as you verify.

• Full path rule including how a workspace path becomes a directory name
• States whether the compression is multi-frame append or single frame — this decides whether one-shot decompression works
• Gives the first-line and per-line structures, naming the sequence and timestamp fields
• Separates chunk events from complete messages
• Separates direct mapping, synthesis required, and inevitable loss

Failures & boundaries

• Measured: the path is $DSH_HOME/sessions/<escaped workspace>/<session uuid>/session.jsonl.zstd. The workspace C://Users//netbe//Documents//blog becomes --C-Users-netbe-Documents-blog-- (colons and slashes become hyphens, with -- at both ends).
• Measured: it is zstd with multi-frame appends. A one-shot decompress returns only the first frame (the 271-byte result came from exactly that mistake); a stream_reader must walk all frames. One 1.4 MB file expanded to 3.36 MB across 5393 lines.
• Measured: the first line is {"type":"session","version":0,"id","createdAt","cwd","parentSession","origin","delegationDepth","agentPreset"}, and each subsequent line is {"type":"<event>","seq":N,"time":<ms>,"data":{}}.
• Measured event mix over 5393 lines: tool-call-chunks, assistant/chunk, reasoning-chunks, tool/call, tool/result, step/start, assistant/message, step/end, text-chunks, todo/write. Chunk events vastly outnumber complete messages, so importing another tool's message-level format turns one answer into a dozen increments.
• So 'rename the file and it works' does not hold: compression must be re-encoded, the event vocabulary mapped, and chunks reorganised against complete messages.
• Blocked on: The DSH side is measured (path escaping, multi-frame zstd, header and event shapes); what is missing is a real sample from the other side. With no Claude Code or Codex session file on hand, the mapping can be reasoned but not measured.

Claim this recipe Back to recipes