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

[WrangleMeThis]

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.