perf(codex): prune historical files for date ranges - #1599

Check if this issue is valid — if so, understand the root cause and fix it. At rust/adapters/codex/src/aggregate.rs, line 147:

<comment>When a Codex file has a preserved mtime more than one day before `--since`, this prefilter drops the entire file and loses in-window usage. Do not treat the one-day mtime window as conservative for preserved mtimes; fall back to inspecting the file (or otherwise retain it) when its mtime cannot prove that no requested events exist.</comment>

<file context>
@@ -125,6 +130,31 @@ pub(super) fn load_groups_from_directory(
+        return;
+    }
+    // ponytail: mtime is a one-day-widened proxy; inspect file tails if preserved mtimes matter.
+    let cutoff = start.saturating_sub(MILLIS_PER_DAY);
+    files.retain(|file| {
+        file.metadata()
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At rust/crates/ccusage-adapter-all/src/loader.rs, line 631:

<comment>When the selected window produces no groups, this recursively scans every Codex source a second time because `load_groups` already collected those files. Return detection from the load pass or reuse its source-presence result to avoid doubling filesystem traversal for out-of-range queries.</comment>

<file context>
@@ -627,23 +627,8 @@ fn load_codex_rows(
-    codex::filter_events_by_date(&mut events, shared)?;
-    let groups = codex::aggregate_events(&events, kind, shared.timezone.as_deref())?;
+    let groups = codex::load_groups(shared, kind)?;
+    let detected = !groups.is_empty() || codex::has_data();
     let speed = codex::resolve_codex_speed(CodexSpeed::Auto);
     Ok(AgentRows {
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At rust/crates/ccusage-adapter-all/src/tests.rs, line 545:

<comment>This test for the PR's headline behavior never exercises the new mtime pruning path. `retain_report_files` (rust/adapters/codex/src/aggregate.rs) returns early when `start > now`, and since the test passes a future `since` of `20990102`, pruning is skipped entirely. The test can only prove detection survives event-level date filtering; if the new mtime pruning wrongly dropped Codex detection, this test would still pass. Choose a `since` in the past (with the fixture file mtime fresh) so the pruning branch runs, or add a companion case that asserts detection after files are actually pruned.</comment>

<file context>
@@ -525,6 +525,31 @@ fn multi_section_codex_fixture_matches_standalone_sections_for_daily_and_session
+
+    let result = loader::load_rows(
+        AgentReportKind::Daily,
+        &fixture_shared("20990102", "20990102"),
+    )
+    .unwrap();
</file context>

Check if this issue is valid — if so, understand the root cause and fix it. At rust/adapters/codex/src/lib.rs, line 33:

<comment>In this perf-focused PR, `has_data()` calls `paths::collect_codex_usage_files(&source.dir)`, which walks the entire session tree, collects every `.jsonl` path, and sorts them — all just to test emptiness. It only short-circuits across sources (`.any`), not once a file is found within a source. That contradicts the AGENTS.md rule that "Detection short-circuits as soon as one usable source file is found." For a large `~/.codex` the detection path re-walks the whole directory. Add an early-exit check (e.g. read_dir and return true on the first file/dir) instead of collecting the full sorted list.</comment>

<file context>
@@ -26,6 +26,14 @@ pub use types::{
+    paths::codex_usage_sources().is_ok_and(|sources| {
+        sources
+            .iter()
+            .any(|source| !paths::collect_codex_usage_files(&source.dir).is_empty())
+    })
+}
</file context>