discover: project auto-detection on Windows scans 0 sessions even when project has 144 session files

Environment

• rtk 0.37.2
• Windows 11 Home (10.0.26200)
• Tested from both Git Bash (MSYS) and PowerShell 7

Summary

rtk discover (default mode = current project) scans 0 sessions on Windows, even when the current project has many session files on disk. Explicit -p <substring> works correctly, so the substring matcher is fine — the bug is in how the current-project filter is auto-derived from CWD.

Reproduction

From C:\Users\fab\OneDrive\F\Estudo\Tecnologia\ESP32\p3a\repo (which has 144 JSONL files under ~/.claude/projects/C--Users-fab-OneDrive-F-Estudo-Tecnologia-ESP32-p3a-repo\):

Invocation	Sessions found
rtk discover -p "" (empty filter)	548 (all)
rtk discover -p "p3a"	144
rtk discover -p "OneDrive-F-Estudo"	188
rtk discover -p "C--Users-fab-OneDrive"	547
rtk discover -a (all projects)	548
rtk discover (auto-detect)	0 :x:

rtk gain and rtk session correctly report this project's activity, so the data is on disk and indexed. Verified the same 0-result from both Git Bash (CWD /c/Users/fab/...) and PowerShell (CWD C:\Users\fab\...), so it isn't an MSYS path-translation issue.

Also reproduced from C:\Users\fab (whose project dir C--Users-fab exists) — auto-detect still finds 0. So it's not specific to long/complex paths.

Likely cause

Claude Code stores sessions at ~/.claude/projects/<mangled>/, where <mangled> is the absolute CWD with :, \, and / all replaced by - (e.g. C--Users-fab-OneDrive-F-Estudo-Tecnologia-ESP32-p3a-repo).

When -p is omitted, discover appears to use the raw CWD as the project substring filter without applying that mangling. Since \, /, and : never appear in any project directory name (all use -), the substring matches nothing.

Fix would be to apply the same [:\/] -> - normalization to the auto-detected CWD before using it as the project filter.

Diagnostics suggestion

rtk discover -vvv does not print the auto-detected project filter value. Adding that under -v/-vv would have made this trivial to confirm without source access.

Workarounds

• rtk discover -p <unique-substring> (e.g. the repo name)
• rtk discover -a

Related

• #1582 proposes flipping discover to default-global, which would mask this bug but not fix it for users who do want per-project scope on Windows.