Cc Session Index — Development skill for Claude Code

cc-session-index (`ccsi`)

English | [繁體中文](/README.zh-TW.md)

Index your local **Claude Code**, **Codex**, and **Pi** `.jsonl` session transcripts into SQLite FTS5 (`tokenize='trigram'`), and stream normalized events across all three tools from a single standard-library Python script.

https://github.com/user-attachments/assets/66ce4fa8-bc2b-47f8-8938-64a539314320

The conversation in the video is made up. The 0.05 s is the same search run on the author's real index (2026-10-20, including Python startup).

Once a transcript folder grows past a few tens of gigabytes, `grep -r` across `.jsonl` files takes too long for an agent to run mid-turn. Most session-memory tools either use SQLite's default `unicode61` tokenizer, which cannot match Chinese, Japanese, or Korean substrings, or pin an English-only embedding model.

On the author's machine (`44 GB` across `53,016` `.jsonl` files, `1.50M` indexed rows, `3.5 GB` SQLite file, measured 2026-10-19), a full build takes `371.5s` and incremental runs take `0.6s–6.0s`.

How it works

1. ccsi index walks the transcript roots for Claude Code, Codex, and Pi. For each file it stores (mtime, size, offset, ino, rows). When a file grows with the same inode, ccsi seeks to the previous byte offset and indexes only the newly appended lines; if the last line is still being written and lacks a trailing newline, the cursor stays at the start of that line until the next run.
2. User and assistant text are written to an FTS5 table using the trigram tokenizer, alongside a message_refs(mid, path) lookup table so per-file replacements and -C context queries use an index instead of scanning FTS5.
3. Tool calls are summarized down to their searchable arguments (Read/Edit/Write/NotebookEdit file paths, Bash commands, Grep/Glob patterns, Skill names and args, Agent/SendMessage prompts). Tool calls with empty inputs ({}), expanded skill bodies (Base directory for this skill:), and blo