← notes from the loom
notes

Reading three tools that never meant to be read

4 min · engineering note

Claude Code writes a JSONL DAG that has to be linearized by parent pointers. Codex writes dated rollout files. Cursor keeps chats in a live SQLite database that is usually locked, under a key namespace with no schema guarantees.

None of these are APIs, and none of them promised to stay stable. The defense is boring and effective: open read-only, tolerate schema drift, pin against captured fixtures, run the tests on Linux, macOS and Windows, and keep each reader small enough that one person can fix it in an afternoon when a release moves the furniture.

Cursor is the instructive one. Its history lives in a SQLite database that the editor holds open while you work, under a key namespace with no schema promise, and the rows that hold a conversation are split from the rows that hold its messages. You cannot lock it, you cannot assume it parses, and you certainly cannot write to it. So the reader opens it read-only, tolerates rows it does not recognise, and treats a locked file as a reason to try again in a minute rather than an error worth showing anyone.

The general rule that fell out of this: never let a reader be the reason something breaks. A format that drifts should cost you one session, not the daemon. A file that vanishes mid-read is normal, because the tool that owns it is still running. And every reader stays small enough that one person can hold it in their head on the afternoon a release moves the furniture.

There is a limit worth stating plainly. Motif can read Cursor sessions but cannot write them, because Cursor has no resume-from-transcript command to write for. That is a property of the tool, not something we are hiding, so a Cursor session can be searched, recalled and handed to Claude Code or Codex, but not asked a question or handed back to Cursor.