[Bug]: server.getUsageSummary scans an unbounded project tree and blocks macOS for 50+ seconds #7088

Summary

On macOS, opening the Usage page can block on server.getUsageSummary for roughly one minute. The slowdown is caused by the local transcript scan, not by the Mac hardware or by Claude actively running.

The issue is especially reproducible when Claude has not been used for months and ~/.claude/projects does not exist: the current resolver falls back to ~/projects, then recursively walks that entire tree looking for .jsonl files.

Reproduction

1. Use T3 Code on macOS with no ~/.claude/projects directory (for example, Claude Code has not been used for months).
2. Have a normal Codex history under ~/.codex/sessions and a non-trivial ~/Projects tree containing build artifacts and unrelated .jsonl files.
3. Open the Usage page, or request server.getUsageSummary.
4. Observe that the request remains pending for 50+ seconds.

Expected behavior

• A missing default Claude transcript directory should be reported as missing and skipped.
• The usage scanner should only walk explicitly configured transcript roots, not an entire home-level project directory as an implicit fallback.
• Usage should load within a bounded, predictable time and expose per-provider scan progress/duration if a large cold scan is unavoidable.

Actual behavior

In the installed nightly bundle, UsageService.resolveTranscriptDirs resolves the default Claude home to the user's home directory, checks <home>/.claude/projects, and returns <home>/projects when that directory does not exist. listTranscriptFiles then recursively calls readdir on every directory and stats every .jsonl file without excluding build directories or other unrelated trees.

This means an inactive/missing Claude installation can make the Usage request scan the complete local project tree.

The same request also scans Codex rollouts. On this machine:

• ~/.codex/sessions: 1,249 JSONL files, about 5.33 GiB total.
• Cached 90-day scan: 910 Codex files, about 4.14 GiB.
• The persisted usage cache is already present and only about 6.4 MB, so cache serialization is not the bottleneck.
• The cache contains 75 stale/ unrelated files classified as Claude transcripts under ~/projects, including simulator logarchive and ASR benchmark JSONL files.

Trace evidence

Environment: b5a216d4-8818-4c48-9585-cd810786edc2

T3 Code Nightly: 0.0.34-nightly.20260815.1101 (cf7bfd1c9397)

Platform: macOS 27.0, Apple Silicon

Trace ID: 1440c415efea5a815352529ecdbefd64

Observed spans from ~/.t3/userdata/logs/server.trace.ndjson:

• ws.rpc.server.getUsageSummary: 54,137.8 ms
• UsageService.readSummary: 54,137.6 ms
• A second consecutive call: 56,908.5 ms
• UsageService.ensureRates: 10.3 ms
• UsageService.resolveTranscriptDirs: 1.7 ms
• UsageService.persistScanCache: 20.8 ms

The uninstrumented gap is therefore inside the directory walk and transcript parsing loop, not rate lookup or cache persistence.

Suggested fix

• Do not fall back from a missing default ~/.claude/projects to ~/projects. Treat the default Claude root as missing unless a custom Claude home was explicitly configured.
• Resolve all enabled provider instances' transcript roots explicitly and deduplicate them.
• Skip known non-transcript directories and/or maintain a directory/file index instead of recursively walking broad roots on every request.
• Add spans/counters around directory walking, file reads, and per-provider scan totals so future slow scans identify the exact root and phase.
• Consider serving the last cached summary immediately and refreshing a cold scan in the background.

Related, but distinct, Usage issues: #5798 and #5805.