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
Maka users may already have valuable coding sessions in Codex, Claude Code, and other agents. Today, Maka can discover some foreign sessions and build a distilled handoff digest, but it cannot migrate a complete external session into Maka as a native Session.
The difficult part is not a single Codex import endpoint. Every external agent has its own storage layout and serialized message format. If format parsing, message cleanup, target Session creation, and product entry points are mixed together, every new agent integration will duplicate infrastructure and leak source-specific branches into Maka.
At the same time, a generic ExternalSessionCleaner or universal external-message intermediate representation would add the wrong abstraction. An external transcript is already a sequence of raw conversation records. The source-specific work is only to convert those records into Maka's existing raw message representation: StoredMessage.
Desired outcome
Provide one small internal abstraction through which multiple external agents can be imported:
each source-specific adapter discovers and reads its own native Session format;
the adapter converts native records directly to Maka StoredMessage[];
there is no shared cleaner, context builder, summary layer, or second message model;
one source-agnostic importer validates and atomically persists the converted Session;
adding another agent requires implementing and registering one adapter, without changing the importer or Maka persistence logic.
The first PR should establish this internal boundary only. It should not expose a new IPC, CLI, HTTP, or public product interface yet.
Design principles
Adapters own formats. Codex, Claude Code, and future agents parse only their own native storage and serialization details.
Maka already owns the canonical message model. Adapters emit StoredMessage[] directly; there is no ExternalMessage IR.
No ExternalSessionCleaner. Any normalization required by a source is part of that source's adapter conversion.
No context synthesis. Migration preserves raw conversation records; it does not summarize them into a prompt or rebuild context.
The importer is deliberately boring. It selects an adapter, applies target Session settings, validates Maka messages, and commits atomically.
No partial Sessions. One invalid converted message must reject the complete import before Session metadata becomes visible.
External stores remain read-only. An adapter must never mutate the source agent's files or database.
Proposed architecture
flowchart LR
subgraph Sources["External agent stores (read-only)"]
Codex["Codex Session"]
Claude["Claude Code Session"]
Other["Other Agent Session"]
end
subgraph Adapters["Source-specific adapters"]
CodexAdapter["CodexSessionAdapter"]
ClaudeAdapter["ClaudeCodeSessionAdapter"]
OtherAdapter["OtherSessionAdapter"]
Contract["ExternalSessionAdapter contract"]
end
subgraph Maka["Source-agnostic Maka import path"]
Registry["ExternalSessionAdapterRegistry"]
Importer["ExternalSessionImporter"]
Validation["StoredMessage canonical validation"]
Store["SessionAuthorityStore.createImportedSession"]
Database[("Maka Session metadata + raw messages")]
end
Codex --> CodexAdapter
Claude --> ClaudeAdapter
Other --> OtherAdapter
CodexAdapter --> Contract
ClaudeAdapter --> Contract
OtherAdapter --> Contract
Importer -->|"resolve by adapter id"| Registry
Registry -.->|"select"| Contract
Contract -->|"ExternalMakaSession / StoredMessage[]"| Importer
Importer --> Validation --> Store --> Database
Loading
The dependency direction is one-way: source adapters depend on the Maka message contract; Maka persistence never depends on Codex, Claude Code, or another source format.
Before persistence, every adapter-produced message is round-tripped through Maka's canonical stored-message decoder. Header creation, messages, and catalog projections are then committed in one transaction.
PR stages
PR 1 — Internal abstraction and atomic import foundation
add ExternalSessionAdapter and ExternalSessionAdapterRegistry;
Problem
Maka users may already have valuable coding sessions in Codex, Claude Code, and other agents. Today, Maka can discover some foreign sessions and build a distilled handoff digest, but it cannot migrate a complete external session into Maka as a native Session.
The difficult part is not a single Codex import endpoint. Every external agent has its own storage layout and serialized message format. If format parsing, message cleanup, target Session creation, and product entry points are mixed together, every new agent integration will duplicate infrastructure and leak source-specific branches into Maka.
At the same time, a generic
ExternalSessionCleaneror universal external-message intermediate representation would add the wrong abstraction. An external transcript is already a sequence of raw conversation records. The source-specific work is only to convert those records into Maka's existing raw message representation:StoredMessage.Desired outcome
Provide one small internal abstraction through which multiple external agents can be imported:
StoredMessage[];The first PR should establish this internal boundary only. It should not expose a new IPC, CLI, HTTP, or public product interface yet.
Design principles
StoredMessage[]directly; there is noExternalMessageIR.ExternalSessionCleaner. Any normalization required by a source is part of that source's adapter conversion.Proposed architecture
flowchart LR subgraph Sources["External agent stores (read-only)"] Codex["Codex Session"] Claude["Claude Code Session"] Other["Other Agent Session"] end subgraph Adapters["Source-specific adapters"] CodexAdapter["CodexSessionAdapter"] ClaudeAdapter["ClaudeCodeSessionAdapter"] OtherAdapter["OtherSessionAdapter"] Contract["ExternalSessionAdapter contract"] end subgraph Maka["Source-agnostic Maka import path"] Registry["ExternalSessionAdapterRegistry"] Importer["ExternalSessionImporter"] Validation["StoredMessage canonical validation"] Store["SessionAuthorityStore.createImportedSession"] Database[("Maka Session metadata + raw messages")] end Codex --> CodexAdapter Claude --> ClaudeAdapter Other --> OtherAdapter CodexAdapter --> Contract ClaudeAdapter --> Contract OtherAdapter --> Contract Importer -->|"resolve by adapter id"| Registry Registry -.->|"select"| Contract Contract -->|"ExternalMakaSession / StoredMessage[]"| Importer Importer --> Validation --> Store --> DatabaseThe dependency direction is one-way: source adapters depend on the Maka message contract; Maka persistence never depends on Codex, Claude Code, or another source format.
Abstract interfaces
Adapters are resolved through a registry with these semantics:
The generic importer does not understand any source format:
The importer writes through one atomic Maka storage operation:
Before persistence, every adapter-produced message is round-tripped through Maka's canonical stored-message decoder. Header creation, messages, and catalog projections are then committed in one transaction.
PR stages
PR 1 — Internal abstraction and atomic import foundation
ExternalSessionAdapterandExternalSessionAdapterRegistry;ExternalSessionImporter;SessionAuthorityStore.createImportedSession(...);StoredMessage[]before writing;PR 2 — Codex adapter
StoredMessagevariants;PR 3 — Explicit Maka import workflow
PR 4 — Additional agent adapters and hardening
Acceptance criteria
StoredMessagerecords and read them back unchanged through Maka's Session store.nameandcwd; source format logic remains inside the adapter.ExternalSessionCleaner, shared external-message IR, or context-generation step.Non-goals for the first PR