Windows: resumed Codex CLI sessions from previous dates may not be detected

[Astiyac]

Summary

I noticed a case where abtop may not detect a resumed Codex CLI session on Windows when the original session was created on a previous date.

New Codex sessions are detected correctly, and resuming a session created earlier on the same day also appears to work. The issue seems to happen when the resumed session's rollout-*.jsonl file remains
under an older dated session directory.

Environment

• OS: Windows
• Agent: Codex CLI
• Collector: CodexCollector in src/collector/codex.rs
• Session data path: ~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl

Observed behavior

1. Start a Codex CLI session on day 1.

2. Exit the session.

3. On day 2, resume that same Codex session.

4. Run:

   abtop --once
   

In this case, the resumed session may not appear in abtop.

Starting a new Codex session on day 2 is detected normally.

Expected behavior

abtop would detect the resumed Codex session as active, even if the session's rollout file is still stored under the original date directory.

Possible cause

From looking at src/collector/codex.rs, the Windows fallback in CodexCollector::map_pid_to_jsonl appears to scan only today's session directory:

~/.codex/sessions/YYYY/MM/DD/

That makes sense as a lightweight fallback, since Windows does not have /proc//fd or lsof in the same way Linux/macOS do.

However, resumed Codex sessions seem to keep using the rollout file from the original creation date, for example:

~/.codex/sessions/2026/07/07/rollout-abc.jsonl

If the current date is:

2026/07/08

then the Windows fallback would scan:

~/.codex/sessions/2026/07/08/

and may miss the active resumed session from 2026/07/07.

Possible fix

One possible fix would be for the Windows fallback to scan ~/.codex/sessions recursively for rollout-*.jsonl files, rather than only scanning today's directory.

The existing strategy of sorting candidates by modification time and assigning the most recent rollout files to detected Codex PIDs could stay the same.

This should leave Linux/macOS behavior unchanged.

Local validation

I tested this locally in a fork by changing the Windows fallback to recursively scan ~/.codex/sessions.

In that fork:

• cargo clippy -- -D warnings passed in GitHub Actions
• cargo test passed in GitHub Actions
• cargo build --release passed in GitHub Actions
• A Windows abtop.exe built via GitHub Actions detected my resumed Codex sessions from previous dates correctly

Note

This is about the existing Codex CLI collector in:

src/collector/codex.rs