Description:
Codeburn incorrectly reports historical Cursor AI usage as new usage if the underlying Cursor database files are modified by background processes.
Steps to Reproduce:
- Have historical Cursor usage stored in
~/.cursor/chats/<hash>/store.db.
- Trigger a database file modification (e.g., Cursor performs an internal migration or vacuum, updating the file's
mtime without changing chat timestamps).
- Run
codeburn to check recent usage.
Expected Behavior:
Codeburn should report usage based on the internal timestamps of the chat records (e.g., December 2025).
Actual Behavior:
Codeburn reports all historical usage in that database as occurring on the day the file was modified (e.g., today).
Root Cause:
When Codeburn parses the Cursor SQLite databases, if it fails to extract or parse the internal message timestamp, it falls back to the file's mtime (fileStat.mtime.toISOString()). Since SQLite databases are frequently touched by the host application for maintenance, mtime is an unreliable indicator of when the AI request actually occurred.
Suggested Fix:
Remove the mtime fallback. Rely strictly on the internal SQLite timestamps (createdAt metadata or similar inside store.db). If a timestamp genuinely cannot be parsed, it should either be skipped, flagged as unknown, or use the earliest known date, rather than surfacing as new billing usage.
Description:
Codeburn incorrectly reports historical Cursor AI usage as new usage if the underlying Cursor database files are modified by background processes.
Steps to Reproduce:
~/.cursor/chats/<hash>/store.db.mtimewithout changing chat timestamps).codeburnto check recent usage.Expected Behavior:
Codeburn should report usage based on the internal timestamps of the chat records (e.g., December 2025).
Actual Behavior:
Codeburn reports all historical usage in that database as occurring on the day the file was modified (e.g., today).
Root Cause:
When Codeburn parses the Cursor SQLite databases, if it fails to extract or parse the internal message timestamp, it falls back to the file's
mtime(fileStat.mtime.toISOString()). Since SQLite databases are frequently touched by the host application for maintenance,mtimeis an unreliable indicator of when the AI request actually occurred.Suggested Fix:
Remove the
mtimefallback. Rely strictly on the internal SQLite timestamps (createdAtmetadata or similar insidestore.db). If a timestamp genuinely cannot be parsed, it should either be skipped, flagged as unknown, or use the earliest known date, rather than surfacing as new billing usage.