Inconsistent chat vs composer log classification in v44.9+

[atxtechbro]

Current Behavior

I've noticed some inconsistencies in how chat and composer logs are being classified, particularly after Cursor v44.9's move to globalStorage. This affects both the count display and categorization in the chat browser UI.

Investigation So Far

While looking into this, I've observed:

1. Chat counts don't match between workspace list and detail views
2. Some composer logs are being counted as chats and vice versa
3. Storage patterns differ between older and newer Cursor versions

Initial Implementation

I've started working on a fix that:

• Extracts shared classification logic
• Adds detailed logging for pattern analysis
• Handles both old and new storage formats
• Maintains backwards compatibility with pre-v44.9 logs

Questions for Discussion

Would appreciate the team's thoughts on:

1. How aggressively should we handle backwards compatibility?
2. What's the best way to identify chat vs composer logs in v44.9+?
3. Should we consider a migration strategy for older logs?

Current Approach

• Using title patterns to differentiate (e.g., # prefix indicates composer)
• Falling back to source/type checks when available
• Adding detailed logging to help understand patterns
• Maintaining support for both old and new storage formats

Next Steps

• Gather feedback on classification approach
• Analyze more log patterns
• Decide on backwards compatibility strategy
• Update documentation

Not ready for PR yet - would love to hear thoughts from @team (@thomas-pedersen @mrmaarten @random-yang ) on this approach first.

Labels: needs-discussion, compatibility, refactor

[lifeinchords]

Thank you for proposing and doing this!

I was wondering how this would continue working, given Cursor's rapid pace of development, with changes to their db schema.

I'm worried about migration scripts/procedures. If they fail, is there a possibility of db corruption and loss of data?
At the same time, I have workspace that are long running projects, 6+ months, and this is my main need - search through all of my history..

I can create some basic wireframes and designs if that helps

[atxtechbro]

After diving deep into Cursor's architecture and seeing their rapid development pace, I think we need to surface some key assumptions and questions:

First, I've been working under the assumption that our primary user need is comprehensive access to chat history (both queries and responses). But is this really what everyone needs? Maybe we should validate this assumption.

Two critical questions I'd love your thoughts on:

• Could we build something simpler that's less tightly coupled to Cursor's internal structure? (Currently they store data across workspace and global SQLite databases, which makes maintaining compatibility challenging)
• What's the absolute minimum feature set we need to preserve to make this tool valuable?

Your wireframes could really help us visualize the core user experience before we dive back into technical implementation. I believe in being transparent - I've gone down some complex rabbit holes trying to maintain compatibility with their evolving platform, and a fresh perspective could help us build something more sustainable.

I'm committed to fostering shared understanding here - let's build something valuable together that serves everyone who's shown interest in this project.