search misses existing file content after snapshot rebuild while tree/read show the file

[ahndohun]

Summary

I am a paid CodeGraff Pro user and I am seeing inconsistent local codedb search behavior on codedb 0.2.5820.

After rebuilding the local snapshot for /Users/ahndohun/Documents/doran-orchestrator, codedb tree shows the target files, and zigread confirms the text exists in the file, but codedb search returns no results for that exact text.

This makes codedb search unsafe as the primary navigation path for Codex/MCP workflows because a negative result is not reliable.

Environment

• Platform: macOS darwin arm64
• codedb --version: codedb 0.2.5820
• CodeGraff Pro: muonry status reports Codegraff Pro — license valid
• Codex MCP registration:

codedb
  enabled: true
  transport: stdio
  command: /Users/ahndohun/bin/codedb
  args: /Users/ahndohun/Documents/doran-orchestrator mcp
  cwd: -
  env: -
  startup_timeout_sec: 30

Reproduction evidence

From /Users/ahndohun/Documents/doran-orchestrator:

/Users/ahndohun/bin/codedb /Users/ahndohun/Documents/doran-orchestrator tree

The tree includes:

bin/
  doran-openclaw-orchestrator  unknown  63L  0 sym
openclaw/
  maintenance.sh  shell  405L  46 sym

The text exists in the file:

/Users/ahndohun/bin/zigread -L 41-47 bin/doran-openclaw-orchestrator

Output:

41 | if [[ "${OPENCLAW_ORCHESTRATOR_INJECT_POLICY:-1}" == "1" ]]; then
42 |   policy_context="$(cat <<'POLICY'
43 | Doran Orchestrator operating contract:
44 | - AIHero / Matt Pocock skills from AGENTS.md are the first-principle development workflow.
45 | - Use oh-my-codex / OMX only as a secondary runtime and orchestration layer: roles, hooks, HUD/state, durable goal support, and coordinated execution.
46 | - When AIHero and OMX overlap, prefer AIHero skill semantics and use OMX for support after acceptance criteria and verification are clear.
47 | - Keep OpenClaw, Codex, and OMX runtime state, credentials, tokens, transcripts, and logs out of the repository.

But search misses it:

/Users/ahndohun/bin/codedb /Users/ahndohun/Documents/doran-orchestrator search "Doran Orchestrator operating contract"

Output:

✓ loaded snapshot  139 files  ⚡ 2.9ms
✗ no results for "Doran Orchestrator operating contract"

At the same time, another exact search against a different newly added markdown file succeeds:

/Users/ahndohun/bin/codedb /Users/ahndohun/Documents/doran-orchestrator search "OpenClaw Maintenance Loop"

Output:

✓ loaded snapshot  139 files  ⚡ 3.3ms
✓ 1 results for "OpenClaw Maintenance Loop"  ⚡ 20.0µs
  docs/openclaw-maintenance.md:1  # OpenClaw Maintenance Loop

Earlier in the same debugging session, before forcing a snapshot rebuild, the reverse happened: the old shell-file sentinel was found, while newly created maintenance docs/scripts were visible only after the snapshot was moved out of the way and rebuilt.

Expected behavior

If codedb tree includes a file and the file content contains an exact substring, codedb search <substring> should find it or clearly report why that file/content is not in the trigram index.

Actual behavior

tree and zigread prove the file/content exists, but codedb search returns no result for an exact string.

Impact

This breaks the CodeGraff-first workflow in Codex. Agents treat an empty codedb search result as authoritative and then make incorrect decisions or fall back to raw shell tools. For a paid Pro setup, this is a serious reliability issue.

Requested resolution

Please provide an official fix or a supported diagnostic path for verifying/rebuilding the search index. If the product cannot reliably support local search freshness in the paid workflow, please advise on refund handling under the CodeGraff refund policy.