grepai status reports 'Files indexed: 0' after successful scan in nested linked worktree

[islamsaka]

Summary

In a nested linked git worktree layout (./.worktrees/...), grepai watch can complete a full initial scan and grepai search can return current results, but grepai status still reports Files indexed: 0.

This appears to be a status/accounting bug rather than a full indexing failure, because the semantic index is usable after the scan completes.

This is not an exact duplicate of #189. That issue is about nested linked worktree auto-init/watch behavior. In my case, the worktree is already initialized and the watcher completes successfully, but status still reports zero files.

Version / Environment

• grepai version 0.35.0
• macOS
• Git linked worktree nested under repo root
• Embedder: OpenAI text-embedding-3-small
• Store backend: Qdrant

Repo layout

Main repo:

• /path/to/repo

Nested linked worktree used during development:

• /path/to/repo/.worktrees/repro

What I expected

After grepai watch completes its initial scan, grepai status should report a non-zero file count that matches the indexed project.

What actually happened

After a successful full scan, the watcher log showed:

• Initial scan complete: 274 files indexed, 626 chunks created, 0 files removed, 0 skipped
• Symbol index built: 239 symbols extracted
• [RUNNING] ... steady

But grepai status immediately afterwards showed:

grepai index status
Files indexed: 0
Total chunks: 626
Index size: N/A
Provider: openai (text-embedding-3-small)
Watcher: running

At the same time, semantic search was clearly using the fresh index. For example, semantic queries returned newly added application and migration files from the current code change.

So the index existed and was queryable, but status still claimed Files indexed: 0.

Reproduction

1. Use a repo with grepai initialized in the main worktree.

2. Create a linked worktree under the repo root, for example:

   git worktree add .worktrees/repro -b wt/repro

3. Work in the main repo and make code changes.

4. Start or restart the watcher from the main repo:

   grepai watch --background

   or

   grepai watch

5. Wait for the initial scan to finish.

6. Run:

   grepai status
   grepai search "some semantic query that should hit the new code" --json --compact

Observed behavior in my run

Watcher log:

Starting grepai watch in /path/to/repo
Performing initial scan...
Initial scan complete: 274 files indexed, 626 chunks created, 0 files removed, 0 skipped
Building symbol index...
Symbol index built: 239 symbols extracted
[RUNNING] /path/to/repo - steady

Status output right after:

grepai index status
Files indexed: 0
Total chunks: 626
Index size: N/A
Provider: openai (text-embedding-3-small)
Watcher: running

Why I think this is a bug

There is a mismatch between:

• watcher accounting (274 files indexed),
• index usability (grepai search returns fresh results), and
• grepai status (Files indexed: 0).

That suggests the status command is reading stale or incomplete file-count metadata, or is resolving the wrong project/worktree context while still reading chunk metadata from the active index.

Possible related issues

• Nested linked worktrees don't auto-init consistently; watch retries with missing .grepai/config.yaml #189 nested linked worktrees / auto-init inconsistencies
• [Bug]: Ollama provider scans files but doesn't embed (Windows, v0.24.0) #87 older report of watch succeeding while status still shows zero files

If useful, I can provide additional sanitized logs.

[islamsaka]

Additional data point: this was not the first full scan on this repo/worktree setup. I had already run one earlier full scan before reproducing the issue again. That makes me think this is less likely to be a first-run/bootstrap race and more likely to be a persistent status/accounting problem, or a nested-worktree project identity mismatch where watch/search and status are reading different metadata paths.