fix(sensor): add Windows path support to CursorParser and ClineParser - #28
Open
Rahul-s-007 wants to merge 1 commit into
Open
fix(sensor): add Windows path support to CursorParser and ClineParser#28Rahul-s-007 wants to merge 1 commit into
Rahul-s-007 wants to merge 1 commit into
Conversation
The top-level README claims ADR observes agents "on macOS, Linux, and Windows," but CursorParser and ClineParser only checked macOS (Library/Application Support/...) and Linux (.config/...) install paths. On a Windows machine neither exists, so both parsers silently fall through to the (also nonexistent) Linux path and return zero entries - a blind spot for two of the most commonly Windows-installed tools this product claims to observe. Sensor/README.md's own compatibility table was honest about the "macOS, Linux" only ceiling, so this closes a real, disclosed gap rather than fixing a doc lie. Adds an %APPDATA%-based Windows branch to both parsers' path-detection logic, preserving macOS-first precedence. Verified (two independent sources) Windows path for Cursor: %APPDATA%\Cursor\User\globalStorage\ state.vscdb - the standard Electron-app-data convention already mirrored by the existing macOS/Linux split. Cline is a VS-Code extension hosted inside Cursor (per the existing paths targeting .../Cursor/User/globalStorage/saoudrizwan.claude-dev/tasks), so its Windows path follows the same confirmed root. No shared helper introduced: Sensor/CONTRIBUTING.md says to keep parsers self-contained, the existing code already duplicates the macOS/Linux logic per-parser with no abstraction, and the new logic is ~4 lines/parser. Confirmed via a full-repo pass that no Windows path handling exists anywhere else in Sensor/adr_sensor/. The other four parsers don't have this gap: ClaudeParser/CodexParser already use bare Path.home()-relative paths that resolve correctly on Windows with no branching needed, and ClaudeDesktopParser/WarpParser target apps with no Windows release to begin with. Also backfills CursorParser's test coverage (previously zero, unlike its sibling parsers) with a basic content-parsing test using the same synthetic-SQLite-fixture technique already established for WarpParser. Updates Sensor/README.md's compatibility table for the two affected rows. No change needed to the top-level README's platform claim - it becomes accurate for these two sources. Fixes uber#21 Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What type of PR is this? (check all applicable)
Related issue: Closes #21
What changed?
CursorParserandClineParsernow check for an%APPDATA%-based Windows install path, added as anelifbetween the existing macOS check and the final Linux fallback, so macOS still takes precedence when present (regression-guarded by a test). Verified (two independent sources) real Windows path for Cursor:%APPDATA%\Cursor\User\globalStorage\state.vscdb, mirroring the same Electron-app-data convention already hardcoded for macOS/Linux. Cline's Windows path is derived from that same confirmed Cursor root, since it's a VS-Code extension hosted inside Cursor per the existing macOS/Linux paths. Also backfillsCursorParser's test coverage, which was previously zero (unlike its sibling parsers), using the same synthetic-SQLite-fixture technique already established forWarpParser. UpdatesSensor/README.md's compatibility table for the two affected rows.Why?
The top-level
README.mdclaims ADR observes agents "on macOS, Linux, and Windows." In practice, neither parser had any Windows branch, so on a Windows machine both silently returned zero entries for two of the most commonly Windows-installed tools this product claims to observe. Confirmed via a full-repo pass that this is a real, isolated gap:ClaudeParser/CodexParseralready work on Windows with no branching needed, andClaudeDesktopParser/WarpParsertarget apps with no Windows release at all.How did you test it?
Added 8 new tests (4 per parser): macOS still wins when present (regression guard), Windows selected when
APPDATAis set and the path exists, falls back to Linux when nothing exists orAPPDATAis unset (no crash), and falls back to Linux whenAPPDATAis set but the path itself doesn't exist. Plus aCursorParsercontent-parsing test against a synthetic SQLite fixture. All usemonkeypatchonPath.home/APPDATA, no dependency on real local files, perSensor/CONTRIBUTING.md.Ran the full suite,
pytest tests/ -v:74 passed, 1 warning (pre-existing, unrelated) — click to expand
Potential risks
Low. The Windows branch only activates on platforms where
APPDATAis set and the specific path exists, on today's macOS/Linux CI and dev machines,os.environ.get("APPDATA")returnsNoneand the new code path is a no-op, falling straight through to the existing Linux fallback exactly as before.