Codex is too heavy for it to process, ccsage-codex can do it though, even if it takes a bit of time.

[sbrusse-git]

⏺ Diagnosis confirmed:

• ~/.codex/sessions/ is 45 GB with 10,290 JSONL files
• codeburn's Codex parser has no result cache (only LiteLLM pricing is cached)
• Each codeburn invocation re-parses all 45 GB → pegs CPU forever
• The Mac app shells out to codeburn status --format menubar-json every 30s, so it's stuck for the same reason

The terminal process I killed had been running 2+ minutes without finishing. Cursor has a cache file (~/.cache/codeburn/cursor-results.json); Codex does not.

Workarounds, in order of effort:

1. Skip Codex entirely (fastest):
   codeburn --provider claude
2. For the menubar app, there's no flag to pass — it always scans all providers.
3. Date-scope the run (still has to walk the tree):
   codeburn today
4. Probably faster but still touches every file's mtime.
5. Archive old Codex sessions (real fix):
   mv ~/.codex/sessions/2024 ~/.codex/sessions-archive/
   mv ~/.codex/sessions/2025 ~/.codex/sessions-archive/
6. Keep only recent months in the live dir.
7. Open an issue at https://github.com/getagentseal/codeburn/issues asking for a Codex result cache like Cursor has.

Want me to try codeburn --provider claude to confirm it loads when Codex is skipped, or move old Codex sessions out of the way?

[iamtoruk]

Thanks for the detailed diagnosis. This is a real problem and the fix is now merged.

Root cause

Two compounding issues:

1. Discovery reads entire files: readFirstLine() was calling readSessionFile() which reads the full file just to get line 1. For 10,290 files totaling 45 GB, this meant reading ~45 GB during discovery alone, before any parsing starts.

2. No result cache: Unlike Cursor (which has cursor-results.json), Codex had no result cache. Every 30-second refresh re-parsed all 10K session files from scratch.

Fix (3 changes, merged in #185)

1. readFirstLine now reads only 16 KB using fs.open() + a fixed buffer instead of loading the whole file. This alone turns discovery from "read 45 GB" to "read ~160 MB" (10K x 16KB).

2. Per-file result cache (codex-results.json). Each file is fingerprinted by mtime + size. On cache hit, parsed calls are returned instantly without reading the file at all. First run populates the cache; subsequent runs are near-instant for unchanged files.

3. Cache-accelerated discovery. If a file's results are already cached, discovery skips the readFirstLine validation entirely and pulls the project name from the cache. On warm cache, discovery does only stat() calls (checking mtime/size), no file reads at all.

Performance impact

Scenario	Before	After
First run (cold cache)	~45 GB read, 2+ min	~45 GB read once, results cached
Subsequent runs (warm cache)	~45 GB read again	stat() calls only, <1s
30-second refresh	Full re-parse	Cache hits, near-instant

Update to the latest version to get the fix. Your workaround of archiving old sessions is still valid for reducing first-run time.