You want to remove a function, rename it, or just understand the blast radius of a change. Shift+F12 is the move I trust for that. And yet, after a long Antigravity session, you eventually hit a moment where the panel comes back empty, or shows one caller when you know there are five.
If you are about to ask the agent to "replace this function everywhere," a silent gap in Find References is the kind of bug that ships. The agent rewrites what the language server told it about, leaves the rest untouched, and you find out at runtime.
I have shipped broken refactors because of this more than once, so I keep a small mental playbook organized by cause. Here it is, in the order I actually run through it: first the cross-cutting check, then TypeScript, then Python, then monorepos.
The first three things to verify
Find References is answered by two layers in Antigravity: the language server (LSP) for the file's language, and Antigravity's own workspace index. When results are missing, one of them is silent, and the fix depends on which one.
Three quick checks before doing anything heavier:
- The LSP status bar shows "Idle" — if it still says "Indexing," wait it out
- The target file actually lives under your workspace root (not symlinked from elsewhere)
- Your
files.excludesettings do not hidenode_modules,.venv, ordistso aggressively that real source paths are filtered out by accident
When the LSP is mid-indexing, Find References returns "what I have parsed so far," not an error. That looks identical to a broken state. If you see Indexing... 70% in the status bar, just wait — running it before completion is genuinely meaningless.
TypeScript: the four patterns that cover almost every case
Most missing references in TypeScript fall into one of four patterns.
(1) Files outside tsconfig.json's include
The single most common cause. Anything not listed in include is invisible to the TypeScript Server, and calls coming from those files do not appear.
// tsconfig.json
{
"include": [
"src/**/*",
"scripts/**/*" // omit this and references from scripts/ silently drop out
],
"exclude": ["node_modules", "dist", ".next"]
}The fastest way to confirm: run npx tsc --listFiles and grep for the file you expect to be discoverable.
npx tsc --listFiles | grep "scripts/migrate.ts"
# no output means it is not in the project — add it to include(2) Calls coming from .js files
If a TypeScript function is invoked from a JavaScript file, the TS server will not parse that JS unless you opt in. Until then, those call sites are invisible to Find References.
{
"compilerOptions": {
"allowJs": true,
"checkJs": false // skip JS type-checking if you only want symbols
}
}(3) Dynamic imports and string-keyed dispatch
Patterns like import('./pages/' + slug) or handlers[name]() cannot be resolved statically by the language server, no matter what tool is running it. Antigravity is not the bug here — the language is. Before asking an agent to refactor, grep for these constructs first.
grep -rn "import(" src | head
grep -rn "handlers\[\|registry\[" src | head(4) Stale .tsbuildinfo after a branch switch
After switching branches with build artifacts left over, the incremental build info can disagree with what is actually on disk, and the TS server will trust the cache. Delete it.
find . -name "*.tsbuildinfo" -deletePython: the two issues that actually trip people up
For Python, Find References is answered by Pylance or Pyright. In my experience, two issues account for almost every empty result.
(1) Missing include in pyrightconfig.json
Same logic as TypeScript: anything outside include is not analyzed.
{
"include": ["src", "tests", "scripts"],
"exclude": ["**/__pycache__", ".venv", "build"],
"venvPath": ".",
"venv": ".venv"
}(2) The virtual environment is not actually selected
If Antigravity does not know which .venv you are using, references that flow through modules installed only in that venv will be broken. Open the command palette, run Python: Select Interpreter, and pin the project's .venv/bin/python. Then restart Pylance via Pylance: Restart Server.
I commit pyrightconfig.json to the repo on every Python project I want to maintain long-term. It costs nothing and means that a different machine, or a teammate, gets the same Find References behavior I get.
Monorepos: the cross-package gap
In pnpm workspace, Yarn workspace, Turborepo, and Nx setups, you frequently see Find References return only call sites within the same package, missing the ones from sibling packages. Two causes do almost all the damage.
The first is missing references in tsconfig.json. Project references are how TypeScript stitches together package boundaries. Without them, each package is its own island.
// packages/ui/tsconfig.json
{
"extends": "../../tsconfig.base.json",
"compilerOptions": { "composite": true, "outDir": "dist" },
"references": [{ "path": "../core" }]
}The second is launching Antigravity from inside a package. If you run cd packages/ui && antigravity ., the workspace root is wrong and the index never sees your other packages. Always open Antigravity at the monorepo root — the directory that contains pnpm-workspace.yaml or turbo.json.
When nothing above worked
This is my last-resort sequence, in order:
- Run
Developer: Reload Windowfrom the command palette - Delete build artifacts:
.next/,dist/,build/,.cache/ - Delete
node_modules/.cache/and~/.cache/typescript/ - Quit Antigravity entirely and reopen
- If still empty, edit the target file by one character and save it
Step 5 is unglamorous but works often enough to be worth knowing. The LSP keeps an internal "last edit reflected" flag on every open file, and very rarely it goes stale. Adding and removing a space, then saving, is enough to wake it up.
A self-check before you let an agent do the rewrite
Before I hand a refactor to the Antigravity agent, I always cross-check the Find References count against grep. If the numbers disagree, the agent will too.
# Find References shows 4 hits
# vs
grep -rn "fetchUserProfile" src --include="*.ts" --include="*.tsx" | wc -l
# If grep says 6, the language server is missing 2 call sitesWhen they do not match, something above is silent. Reconcile that before letting the agent touch anything. Refactor safety is bounded by reference completeness, not by the model.
Companion reads
If the broader symptom is "the LSP itself is dead," see Diagnosing an unresponsive language server in Antigravity. If the agent is acting on stale context rather than missing references, Diagnosing and fixing codebase-context drift in Antigravity is the one to read. And when the symptom is the workspace index never finishing, Fixing a stuck workspace index in Antigravity covers the layer below.
A small habit that keeps this from happening twice
After this bit me a few times, I added a tiny pre-flight check to most of my repos. It runs tsc --listFiles (or pyright --outputjson for Python), counts the files, and compares the number against git ls-files | wc -l. If the gap is larger than expected, the script prints a warning so I know the project graph is incomplete before I start refactoring.
# scripts/check-references.sh
EXPECTED=$(git ls-files "*.ts" "*.tsx" | wc -l)
ACTUAL=$(npx tsc --listFiles 2>/dev/null | grep -E "\.tsx?$" | grep -v node_modules | wc -l)
DIFF=$((EXPECTED - ACTUAL))
if [ "$DIFF" -gt 5 ]; then
echo "WARN: $DIFF TS files are outside the project graph — Find References will miss them"
fiTen lines, and it has saved me several embarrassing reverts. The lesson I keep relearning is that "the agent rewrote everything" is only as true as the symbol graph the agent had access to.
On the difference between "no results" and "wrong results"
One last distinction worth keeping in mind. Find References returning zero results is a loud failure — you notice it. Find References returning a subset of the real call sites is a quiet failure, and it is the one that ships bugs. So when I am about to do a non-trivial rename, I do not just check that the panel has hits. I cross-check that the count matches grep, and if I am moving fast, I open one of the listed call sites and verify by eye that the symbol is the one I think it is. It takes 30 seconds and it has stopped me from breaking production more times than I can count.
The cleanest mental model I have: trust the language server only after you have proven what it can see. Thanks for reading.