C:/Program Files/Git/stats panel undercounts Active days vs local session JSONLs (24 on disk → 8 reported)

Environment

• Platform: Windows 11
• Claude Code desktop app: 2.1.111
• Claude Code CLI (npm): 2.1.122
• entrypoint: "claude-desktop" per ~/.claude/sessions/<pid>.json
• Filter selected: All

Bug

The /stats panel "Active days" metric significantly undercounts compared to what's actually present on disk in ~/.claude/projects/*/*.jsonl.

| Metric | Panel reports | Actual on disk |
|---|---|---|
| Sessions | 12 | 12 ✓ |
| Active days | 8 | 24 ✗ |

The Sessions count matches the JSONL file count exactly, so the panel is reading the right files — but the day-extraction logic is wrong.

Reproduction / Verification

On any machine with multiple session JSONLs spanning many days, run:

import json, os, glob
base = os.path.expanduser('~/.claude/projects')
days = set()
for jsonl in glob.glob(os.path.join(base, '*', '*.jsonl')):
    with open(jsonl, encoding='utf-8') as f:
        for line in f:
            try:
                rec = json.loads(line)
                ts = rec.get('timestamp') or rec.get('createdAt') or ''
                if isinstance(ts, str) and len(ts) >= 10:
                    days.add(ts[:10])
            except: pass
print(f'Distinct active days on disk: {len(days)}')

Then compare against what /stats reports. In my case: 24 vs 8.

My data

On-disk distinct days (Mar 18 – Apr 28 2026, 24 days total):

2026-03-18, 2026-03-19, 2026-03-20, 2026-03-26, 2026-03-27,
2026-03-30, 2026-03-31, 2026-04-01, 2026-04-07, 2026-04-08,
2026-04-09, 2026-04-10, 2026-04-13, 2026-04-14, 2026-04-15,
2026-04-16, 2026-04-17, 2026-04-18, 2026-04-20, 2026-04-21,
2026-04-22, 2026-04-23, 2026-04-27, 2026-04-28

/stats panel shows only 8 of these. Persists after upgrading the CLI from 2.1.111 → 2.1.122.

Suspected causes

1. The panel may be sampling from a single session/project rather than all JSONLs
2. Possible hidden retention window even when "All" is selected
3. Day-extraction may be looking at a wrong field (e.g., session start time vs per-message timestamps)

Long-running sessions that span multiple days (resumed across days, appended to one JSONL) may be the trigger — those should still contribute multiple distinct days but appear to be counted as one.

Impact

Cosmetic but misleading — users like me end up troubleshooting "missing days" for hours thinking it's a data-loss bug, when actually all the data is present and the panel's calc is just wrong.