Feature: index Cursor Agent (IDE + CLI) transcripts from `~/.cursor/projects/`

[driftfox]

Problem

/recall indexes Claude Code (~/.claude/projects/), Codex (~/.codex/sessions/), and pi (~/.pi/agent/sessions/), but not Cursor Agent sessions.

Cursor stores agent transcripts separately:

~/.cursor/projects/<encoded-workspace>/agent-transcripts/<session-uuid>/<session-uuid>.jsonl

Users who work primarily in Cursor IDE or agent / Cursor CLI (agent --resume, agent resume, agent ls) cannot search those conversations with /recall. Example failure mode:

python recall.py "sort order" --project quick-gtasks
# No matching sessions found.

Meanwhile the same topic exists in Cursor transcripts under e.g. c-Users-*-src-quick-gtasks/agent-transcripts/....

Proposed solution

1. New source: cursor

   • Glob ~/.cursor/projects/**/agent-transcripts/*/*.jsonl (only files where parent dir name equals file stem, i.e. canonical uuid/uuid.jsonl layout).
   • Add --source cursor filter; tag results [cursor].

2. Parser: parse_cursor_session

   • Each JSONL line: {"role": "user"|"assistant", "message": {"content": [...]}}.
   • Reuse existing extract_text(): index text blocks only; skip tool_use and other block types (same policy as other sources).
   • Project path: prefer working_directory from Shell tool_use blocks in the transcript; fall back to decoding the workspace slug after projects/ (slug decode cannot recover hyphens inside folder names, e.g. quick-gtasks splits to quick + gtasks).
   • Timestamp: file mtime (transcripts do not carry per-line timestamps today).
   • Session ID: UUID from filename / parent folder.

3. read_session.py

   • Detect Cursor via path (/.cursor/projects/ + /agent-transcripts/) or message shape.
   • Pretty-print user/assistant text like other sources.

4. Resume instructions (document in SKILL.md)

   cd /path/to/project
   agent --resume <session-uuid>    # or: agent resume / agent ls

5. Upgrade note

   python recall.py --reindex "test"

Acceptance criteria

• recall "sorting" --project quick-gtasks returns Cursor sessions when transcripts exist (--project uses prefix or substring match).
• --source cursor limits to Cursor only.
• read_session.py <cursor-transcript.jsonl> prints user/assistant turns.
• Unit tests with synthetic JSONL + optional integration test on hosts with ~/.cursor/projects/.
• SKILL.md / README / CHANGELOG updated; version bump (suggest 0.5.0).

Implementation notes (for contributors)

Area	Detail
Collision risk	Session IDs are UUIDs; unlikely to collide with Claude/Codex/pi keys.
Noise	Skip numeric-only project slugs (1768486658315) and empty decoded paths for --project matching.
Performance	Same mtime-based incremental indexing as existing sources; Cursor glob is one extra pass.
Privacy	Same as today: index lives in ~/.recall.db (mode 600); only user/assistant text indexed.

Related

• Cursor Agent CLI: agent --help (--resume, --continue, agent ls).
• Transcript layout observed on Cursor 3.4.x (Windows); confirm on macOS/Linux before release.

[Necmttn]

Cursor support will be more debuggable if it lands as a provider-normalized record shape.

I would store source=cursor, session UUID, project slug, transcript path, cwd evidence, first/last timestamps, parser version, and skipped/unknown block counts. Then recall results can explain both what matched and what the parser intentionally omitted.

---

Generated with ax.

[driftfox]

Cursor support will be more debuggable if it lands as a provider-normalized record shape.

I would store source=cursor, session UUID, project slug, transcript path, cwd evidence, first/last timestamps, parser version, and skipped/unknown block counts. Then recall results can explain both what matched and what the parser intentionally omitted.

Generated with ax.

Makes sense for debuggability. This PR keeps scope to indexing Cursor agent-transcripts with the same (metadata, messages) pattern as the other sources. Storing project slug, cwd evidence, skip counts, and parser version in the DB and CLI output would be valuable, but it would touch shared Recall infrastructure rather than Cursor support alone. I am keeping my PR scoped to Cursor indexing; if you want the broader normalized metadata work tracked, could you open a separate issue for it?