Anyone else having weird issues with Cursor's codebase indexing? It misses files.

I've been conducting a systematic evaluation of Cursor's codebase indexing capabilities over the past several weeks, primarily within a large, multi-service Go and Rust monorepo structured with Bazel. My initial hypothesis was that the indexer would struggle with generated code and complex build system paths, but the observed behavior is more nuanced and, frankly, problematic for reliable daily use.

The core issue manifests as a persistent failure to index a non-trivial subset of source files, leading to incomplete or contextually incorrect autocompletions and "search workspace" results that are demonstrably incomplete. This isn't about ignoring `node_modules` or `target/` directories; it's about overlooking first-party source files within clearly defined source roots.

Here are my specific observations and a reproducible scenario:

* **Pattern of Omission:** The indexer seems to inconsistently parse directories with a high number of files (>100). In one service directory (`/services/order-service/internal/processor/`), it indexed only 78 of 112 `.go` files. The missing files were not outliers; they shared similar naming conventions and were referenced by already-indexed files.
* **Build System Interference:** In the Rust side of the repo, files referenced in `mod.rs` but whose corresponding `.rs` file paths are generated by a `build.rs` script appear to be completely invisible. Cursor's indexer does not seem to execute or respect the output of user-space build scripts when constructing its file map.
* **Symlink Handling:** A portion of our codebase uses symlinks for shared protocol buffer definitions (`/api/protos -> /shared/protos`). Cursor appears to follow the symlink but then fails to index the actual `.proto` files at the destination, treating the directory as empty.

To illustrate, here's a simplified view of the problematic structure:

```
monorepo/
├── services/
│ └── order-service/
│ ├── internal/
│ │ └── processor/ # Cursor indexes ~70% here
│ │ ├── payment.go # Indexed
│ │ ├── validation.go # Indexed
│ │ └── legacy/ # NOT INDEXED (40 files)
│ └── BUILD.bazel
├── shared/
│ └── protos/ # Physical location
│ ├── order.proto # NOT INDEXED via symlink
│ └── payment.proto
└── api/
└── protos -> ../shared/protos # Symlink
```

**Attempted Remediations (All Ineffective):**
* Manually triggering "Rebuild Index" from the command palette multiple times.
* Exiting and restarting Cursor, then reopening the project.
* Adding and removing the root directory and subdirectories from the Cursor workspace.
* Verified `.cursorignore` does not exist in the project.

The inconsistency introduces a significant cognitive tax. You cannot trust that "Find All References" or "Go to Definition" will be comprehensive, which undermines the primary value proposition of an AI-assisted editor that claims deep codebase awareness.

My current environment is Cursor version 0.37, on macOS, with the project opened from a local SSD. Has anyone else undertaken a methodical review of indexing completeness and encountered similar patterns? More importantly, has anyone identified a reliable workaround or configuration setting that forces a more thorough, file-system-level scan, perhaps bypassing some of the inferred heuristics the indexer seems to use?