Windows: `roborev summary` per-repo filter excludes all jobs; `codex` token usage never captured

[ghbaud]

Environment

• OS: Windows 11 Pro (build 26200)
• Shell: MINGW64 (Git Bash for Windows)
• roborev: v0.52.0
• Agent: codex (codex-cli 0.118.0, installed via npm)
• Repo path format: C:\Users\<user>\Projects\<repo> (Windows-native working directory)

Summary

Two independent bugs on Windows. Combining here because they surface together on first use. Happy to split into separate issues if preferred.

---

Bug 1: roborev summary per-repo filter matches nothing

Path-separator inconsistency between the stored repo_path and the filter value causes the per-repo summary view to return zero even when completed reviews exist.

Reproduction

$ roborev review --wait      # runs against HEAD, passes
$ roborev list               # confirms job stored
ID  SHA      Repo        Agent  Status  Time
1   d29d418  <repo>      codex  done    25s

$ roborev summary            # default: current repo, last 7 days
Review Summary: <repo> [last 7d]
Overview
  Total: 0 | Done: 0 | Failed: 0 | Canceled: 0 | Queued: 0 | Running: 0
No review data for this time window.

Root cause evidence

roborev list --json shows the stored path with forward slashes:

"repo_path": "C:/Users/<user>/Projects/<repo>"

roborev summary --json shows the filter value with backslashes:

"repo_path": "C:\Users\<user>\Projects\<repo>"

Workaround matrix

Command	Result
roborev list	works
roborev summary	returns zero
roborev summary --all	works (skips per-repo filter)
roborev summary --repo "C:/Users/<user>/Projects/<repo>" (forward slashes passed in)	still returns zero — value appears to be re-normalized back to backslashes before comparison

Expected

Summary should resolve the current repo via repo_id (as list does) or normalize path separators on both sides of the comparison before filtering.

---

Bug 2: codex agent token usage not captured; backfill-tokens cannot recover it

The Codex CLI emits a complete usage record on its final turn.completed event, but the daemon does not persist it, and backfill-tokens cannot recover it afterward.

Reproduction

$ roborev review --wait --agent codex
(...review output...)

$ roborev backfill-tokens --dry-run
Would update 0/2 jobs (2 skipped, 0 failed)

$ roborev list --json | jq '.[0] | {id, agent, input_tokens, output_tokens}'
{
  "id": 2,
  "agent": "codex",
  "input_tokens": null,
  "output_tokens": null
}

No token fields appear on either list --json or show <id> --json.

Source data available in the raw log

C:\Users\<user>\.roborev\logs\jobs\2.log, four lines of JSONL:

{"type":"thread.started","thread_id":"..."}
{"type":"turn.started"}
{"type":"item.completed","item":{"id":"item_0","type":"agent_message","text":"..."}}
{"type":"turn.completed","usage":{"input_tokens":79150,"cached_input_tokens":2560,"output_tokens":3389}}

Recorded adapter command line

codex exec --json --sandbox read-only -c model_reasoning_effort="high"

Expected

• Daemon: parse turn.completed events on the Codex adapter and populate input_tokens, cached_input_tokens, and output_tokens per job.
• Or backfill-tokens: read these JSONL logs on a subsequent pass and populate the fields from there. The session files and logs both exist, so "skipped" suggests the backfill path is checking only agentsview, not the raw log.

Related observation

roborev summary --all --json currently surfaces duration percentiles but has no tokens or cost fields on the agent breakdown. If token capture lands, consider surfacing aggregates there too.