Search stays empty after successful Codex & Claude checkpoint capture in clean repo repro

Summary

In a brand-new clean GitHub repo, Entire successfully captures a Codex checkpoint, injects an Entire-Checkpoint trailer, pushes entire/checkpoints/v1, and shows the checkpoint in both entire activity and entire dispatch, but entire search / entire checkpoint search still return 0 results for an exact unique token from the committed file.

This repro was done after normalizing git identity and using a strict order of operations to avoid mixed authors, preexisting branches, or GitHub-generated starter commits.

Clean repro

Environment:

• Entire CLI 0.6.1
• macOS arm64
• Agent: Codex CLI

Order of operations:

1. Set git identity to Brian Sweet <brian@agiterra.io>.
2. Create a brand-new local repo with git init -b main.
3. Make the initial commit locally: chore: initial empty repo.
4. Create the GitHub repo from that local history and push it.
5. Run entire enable --agent codex --force --telemetry=false.
6. Start Codex inside the repo.
7. Have Codex create a plain text file with a unique token, commit it, keep the hook-added trailer, push, and exit cleanly.

Controlled repo:

• BrianSweet/entire-orderops-local-canary-20260509-130023

Controlled canary commit:

• commit: df6c7e091ac2493aea605da737cc6780ffca6173
• trailer: Entire-Checkpoint: bee65c2cc740
• committed token: zz-entire-orderops-local-canary-20260509-f6

What works

• git show -s --format=%B HEAD shows the trailer
• git ls-remote --heads origin main entire/checkpoints/v1 shows both branches on origin
• entire checkpoint list shows checkpoint bee65c2cc740
• entire checkpoint explain --commit df6c7e091ac2493aea605da737cc6780ffca6173 --short --no-pager succeeds
• entire dispatch --since 1d --repos BrianSweet/entire-orderops-local-canary-20260509-130023 sees the canary test
• entire activity shows the repo and the Codex checkpoint/commit

What fails

Both of these return 0 results for the exact token from the committed file:

entire search "zz-entire-orderops-local-canary-20260509-f6" --json

entire checkpoint search "zz-entire-orderops-local-canary-20260509-f6" \
  --json --repo BrianSweet/entire-orderops-local-canary-20260509-130023

Observed result from both:

{
  "results": [],
  "total": 0,
  "page": 1,
  "total_pages": 1,
  "limit": 25
}

I rechecked again at 2026-05-09 13:04:24 EDT and search was still empty while entire activity continued to show the checkpointed commit.

Expected behavior

Once a checkpointed commit is visible in entire activity and entire dispatch, an exact-token search from the committed file should be discoverable via entire search / entire checkpoint search after indexing completes.

Actual behavior

Checkpoint capture, local explain, branch push, dispatch, and activity all work, but search remains empty.

Why this repro should be high-signal

This was intentionally reduced to:

• one brand-new repo
• one consistent git author identity
• one local initial commit (not GitHub-generated)
• one plain text canary file
• one Codex session started inside the repo
• one successful trailer-linked commit

So this looks like a search/indexing-specific failure rather than a hook/install/repo-history problem.

Reproduce the issue with the documented CLI commands using the controlled repository, checkpoint commit, and unique token. Start by tracing the search and checkpoint-indexing paths, then compare them with the activity and dispatch paths that already find the checkpoint. Done means the exact token from the committed file appears in both search commands after indexing.