Possible Cursor provider limitation: recent local activity present but recent usage reports are empty

[HashWrangler]

Summary

I’m seeing empty recent Cursor usage in CodeBurn even though local Cursor activity definitely exists on disk.

On this machine, the Cursor SQLite store is present and active, and recent bubbleId rows are being written. However, recent rows appear to have tokenCount.inputTokens = 0 and tokenCount.outputTokens = 0, so CodeBurn ends up reporting zero recent usage for Cursor.

I’m not sure whether this is best classified as a bug, a provider limitation, or an assumption mismatch with newer Cursor local data, but I wanted to report it because the current behavior looks like “no usage” even when recent activity clearly exists.

Environment

• CodeBurn version: 0.7.3
• Install method: npm global
• OS: macOS
• Cursor local DB path: ~/Library/Application Support/Cursor/User/globalStorage/state.vscdb

What I verified

I tried to rule out basic local setup problems first.

• CodeBurn runs normally
• the local Cursor DB exists and is large / active
• recent bubbleId rows are present
• the result reproduces both with the installed CLI and with a source build from current main

So this does not appear to be a simple “no Cursor data exists” case.

What I observed

On this machine:

• there are many recent bubbleId rows in state.vscdb
• older rows with non-zero token counts do exist
• but recent rows appear to have:
  • tokenCount.inputTokens = 0
  • tokenCount.outputTokens = 0

As a result:

• codeburn report --format json --provider cursor --period 30days returns valid JSON, but all usage/session/token aggregates are zero and the arrays are empty
• codeburn export -f json produces no usable recent Cursor usage rows

Why I’m filing this

From a user perspective, this makes Cursor support look like it is not working for recent usage, even though recent local activity clearly exists.

I’m not claiming the bug is definitely in CodeBurn. It may be that Cursor’s local persistence changed, or that CodeBurn’s current Cursor ingest assumptions are now too narrow for some recent Cursor data.

Either way, I think this is worth reporting because the current outcome is a silent “zero usage” result where a more explicit warning or alternate ingest path might be helpful.

Possible explanations

My guess is that one of these is true:

1. recent Cursor rows no longer persist usable token totals on the bubbleId entries CodeBurn reads
2. recent usage exists locally but in a different store/path than CodeBurn currently uses
3. the current Cursor provider logic is too strict for this data shape or time window

Possible improvements

Any of these would help a lot:

• document this limitation more explicitly for Cursor
• emit a warning when recent Cursor activity exists but token fields are all zero
• add provider diagnostics such as:
  • rows scanned
  • rows passing date filter
  • rows failing token filter
• investigate whether newer Cursor builds expose usage more reliably in another local source

Happy to help

I can provide sanitized counts / query results / repro details if that would be useful.