Cursor activity: SQLite adapter for workspaceStorage/*.vscdb

[mishanefedov]

Cursor stores its real AI activity (prompts, generations, composer sessions) in SQLite at:

• ~/Library/Application Support/Cursor/User/workspaceStorage/*/state.vscdb (macOS)
• ~/.config/Cursor/User/workspaceStorage/*/state.vscdb (Linux)

agentwatch today reads only Cursor's config surface — .cursor/mcp.json, .cursor/cli-config.json, .cursorrules, .cursor/rules/*.mdc. Full activity parsing is deferred.

What exists in the DB

Inspection of a live workspace shows:

• ItemTable.aiService.prompts — array of {text, commandType} user prompts. No per-prompt timestamps. No tool calls. No usage.
• ItemTable.aiService.generations — often empty in recent Cursor builds.
• ItemTable.composer.composerData — composer session metadata with composerId, createdAt, totalLinesAdded, totalLinesRemoved, isArchived.

What a thin Cursor adapter could deliver

• One timeline event per composerData entry (timestamp + lines added/removed).
• Prompt events from aiService.prompts, all sharing the composer's createdAt (rough but real).
• No tool_use / tool_result (not persisted). No per-turn token usage or cost (not persisted).

What's blocking a fuller adapter

Cursor doesn't write tool / usage / cost data to disk at all — likely server-side. We can't surface what doesn't exist.

Acceptance

• agentwatch doctor flips Cursor from "config-level only" to "events captured".
• Timeline shows composer sessions with coarse timestamps.
• Limitation is documented clearly so users don't expect tokens/cost.

References

• Investigation during 0.0.3 work.
• Sibling Linear ticket: AUR-187 Gap 3.