Problem
Today the three surfaces each expose a partial slice of a session transcript, and none of them can hand out the whole session:
| Surface |
What exists |
Limit |
| CLI |
maka session-export → .maka-session file |
machine-oriented migration bundle (opaque archive), not human-readable |
| Desktop |
"Export as Markdown" (conversation-markdown.ts) |
renderConversationMarkdown takes the in-memory StoredMessage[] of the open session, so the export covers only what the viewport has loaded; long sessions truncate silently |
| TUI |
/copy all |
clipboard-bound, with a byte cap and no file output |
docs/session-diagnostics.md (#5344) is currently being added to document these exports — documenting is the right move, but the underlying gap stays: there is no path from persistence to a complete, human-readable transcript.
The concrete workflow this blocks: giving a full session to another AI (or a colleague) for debugging — the exact case where a silently-truncated viewport export is worse than no export, because the missing turns are usually the interesting ones.
Proposal
A minimal, read-side-only path: a CLI command that renders a session from persistence to Markdown, e.g.
maka session-export-markdown --workspace-root <dir> --session <id> --out <file.md>
- Full fidelity from the stored ledger: every turn, including tool calls/results and thinking blocks (see questions below), not just what a UI happens to have loaded.
- Reuses the existing semantic assets where possible: same redaction rules (
redactSecrets) and the same output shape as renderConversationMarkdown, so all three surfaces converge on one format over time.
- No wire/protocol changes, no storage schema changes — purely a new reader over data that is already on disk.
Questions for maintainers
- Content boundary: should thinking blocks and raw tool results be in the export by default, redacted, or behind a flag? (These are exactly the parts the Desktop viewport export drops today.)
- Formatter ownership:
renderConversationMarkdown lives under the Desktop renderer. Should it move to a shared package so CLI/Desktop/TUI render identically, or is a CLI-side implementation acceptable to start?
- HTML: is an optional HTML "session reader" output interesting later, or is Markdown the right stopping point to keep the maintenance surface small?
- Relationship to
session-export: should the two commands eventually merge flags, or do they stay deliberately separate (portability bundle vs. human-readable render)?
If the direction looks right, I'm happy to take the implementation on and to bring long-session export cost numbers (memory/time on a 1,000+ turn session) with the PR.
Problem
Today the three surfaces each expose a partial slice of a session transcript, and none of them can hand out the whole session:
maka session-export→.maka-sessionfileconversation-markdown.ts)renderConversationMarkdowntakes the in-memoryStoredMessage[]of the open session, so the export covers only what the viewport has loaded; long sessions truncate silently/copy alldocs/session-diagnostics.md(#5344) is currently being added to document these exports — documenting is the right move, but the underlying gap stays: there is no path from persistence to a complete, human-readable transcript.The concrete workflow this blocks: giving a full session to another AI (or a colleague) for debugging — the exact case where a silently-truncated viewport export is worse than no export, because the missing turns are usually the interesting ones.
Proposal
A minimal, read-side-only path: a CLI command that renders a session from persistence to Markdown, e.g.
redactSecrets) and the same output shape asrenderConversationMarkdown, so all three surfaces converge on one format over time.Questions for maintainers
renderConversationMarkdownlives under the Desktop renderer. Should it move to a shared package so CLI/Desktop/TUI render identically, or is a CLI-side implementation acceptable to start?session-export: should the two commands eventually merge flags, or do they stay deliberately separate (portability bundle vs. human-readable render)?If the direction looks right, I'm happy to take the implementation on and to bring long-session export cost numbers (memory/time on a 1,000+ turn session) with the PR.