You open Antigravity one morning, start typing, and nothing completes. Hovering a variable shows an empty tooltip. "Go to Definition" gives you a click sound and nothing else. If you've been there, you know the frustrating part isn't the breakage itself — it's not knowing where to even start looking.
This article walks through a practical diagnostic order for when a language server (LSP) goes silent inside Antigravity IDE. We'll cover the TypeScript Server, Pylance / Pyright for Python, gopls for Go, and rust-analyzer for Rust, focusing on the failure modes I actually run into — not the textbook ones.
Assume the LSP died silently
The tricky part about language servers is that they often fail without surfacing an error dialog. The UI shows nothing, but underneath, the process has crashed, or it's stuck in an infinite loop and can't reply.
That's why the very first step should be confirming whether the LSP is alive. Looking at actual process state feels slower than guessing, but it's usually the fastest path to recovery.
Open the command palette (Cmd+Shift+P on macOS, Ctrl+Shift+P elsewhere) and run Developer: Show Running Extensions. You'll see a list of every active extension and the state of its child processes. If you see the TypeScript Server or Pylance marked as "Stopped" or "Failed" instead of "Activated", that's your starting point.
The three restart actions worth trying first
Regardless of which language server is acting up, these three steps fix maybe half of all LSP problems I encounter. Try them in order.
1. Restart the language server explicitly.
From the command palette, run the language-specific restart command:
- TypeScript:
TypeScript: Restart TS Server - Python:
Python: Restart Language Server - Go:
Go: Restart Language Server - Rust:
rust-analyzer: Restart server
If the restart alone fixes it, the root cause was usually transient — a memory spike, or an intermediate state where a file you were editing confused the LSP.
2. Reload the Antigravity window.
Run Developer: Reload Window. This restarts the extension host process itself, which helps when restarting one LSP doesn't cut it. Save your work first — reloading keeps unsaved changes in most cases, but I wouldn't bet on it during a debugging session.
3. Clear caches and temporary files.
If neither of the above works, the LSP's cache may be corrupt. Here's where each language keeps its state:
- TypeScript: delete
.tsbuildinfoat the project root andnode_modules/.cache/ - Python (Pylance): delete
~/.cache/pylance/in your home directory - Go (gopls): run
go clean -cacheto clear the build cache - Rust (rust-analyzer): delete the project's
target/directory (yes, this forces a full rebuild, but the LSP index rebuilds along with it)
After deleting the cache and restarting the LSP, the first few seconds will feel slow because the index has to regenerate. If it looks frozen, give it a moment — it usually recovers.
TypeScript Server: three patterns I see repeatedly
When TypeScript's LSP dies, I tend to run into the same three scenarios.
Pattern 1: monorepo type resolution fails
In pnpm workspaces or Turborepo setups, cross-package type references can break when Project references are misconfigured. Double-check that the references field in tsconfig.json actually matches the packages on disk.
// tsconfig.json at the monorepo root
{
"references": [
{ "path": "./packages/ui" },
{ "path": "./packages/core" }
]
}If packages/ui/tsconfig.json doesn't exist, or it lacks composite: true, the TypeScript Server quietly dies. You can find the error log by running Developer: Open Logs Folder and opening exthost.log.
Pattern 2: heavy types pin the CPU
Deeply nested generated types — the kind Zod and Prisma produce — can cause the TypeScript Server to spin at 100% CPU and stop responding.
Two knobs help here. First, set skipLibCheck: true in tsconfig.json to skip type checking inside node_modules. Second, bump typescript.tsserver.maxTsServerMemory in Antigravity's settings to something like 8192 for larger projects:
// .vscode/settings.json or Antigravity's settings.json
{
"typescript.tsserver.maxTsServerMemory": 8192,
"typescript.tsserver.experimental.enableProjectDiagnostics": false
}Project diagnostics run async checks across the whole project, which is great in theory but rough on the LSP in large codebases. Turning it off is a pragmatic default when you're hitting instability.
Pattern 3: too many open files
Antigravity holds a lot of files open in the background. After a branch switch or a fresh clone, you can end up with 100+ editors open, and the TypeScript Server's file watcher hits its limit and hangs.
Running Window: Close Other Editors to close everything except the current file often fixes this. Pair it with an LSP restart for best results.
When Pylance / Pyright silently gives up
The single most common Python LSP issue I see is a misconfigured interpreter. Pylance reads type information from the selected interpreter's site-packages, so if you created a .venv but Antigravity is still pointing at the system Python, every third-party import will appear as unresolved.
Run Python: Select Interpreter from the palette and pick .venv/bin/python (or .venv/Scripts/python.exe on Windows) explicitly. To pin it in settings:
{
"python.defaultInterpreterPath": "${workspaceFolder}/.venv/bin/python",
"python.analysis.extraPaths": ["./src"],
"python.analysis.typeCheckingMode": "basic"
}Setting typeCheckingMode to strict can overwhelm Pylance with errors in a new codebase, making it slow to respond. I prefer starting at basic and raising it to strict only once the project is stable.
Another subtle trap: if your pyproject.toml has a [tool.pyright] section and your editor settings also define things like venvPath or extraPaths, Pylance doesn't know which wins. Keeping the configuration in pyproject.toml and leaving editor settings minimal is the less confusing path.
gopls and rust-analyzer pitfalls
When gopls doesn't respond, the first thing I check is whether GOPATH and GOMODCACHE are visible to the editor. They might be correctly set in your terminal but never reach Antigravity if you launched it from the GUI.
On macOS and Linux, GUI-launched apps don't read ~/.zshrc or ~/.bashrc. You need either launchctl setenv GOPATH /Users/you/go (macOS) or a user-level systemd service to pass env vars through. The easiest fix is simply launching Antigravity from a terminal with antigravity ..
For rust-analyzer, the most common failure is a corrupt target/ index that prevents the LSP from starting. cargo clean followed by reopening the project usually fixes it. Also remember that rust-analyzer takes several minutes to index a large project the first time — watch the status bar progress indicator before assuming it's hung.
# rust-toolchain.toml
[toolchain]
channel = "stable"
components = ["rust-analyzer", "rust-src"]Adding rust-src in rust-toolchain.toml makes standard library type info available to the LSP, which noticeably improves completion quality.
Isolating an extension conflict
When the LSP feels sluggish, the culprit isn't always Antigravity itself — a recently installed extension can be the real cause. The reliable way to find out is to start from "everything disabled" and add things back.
Run Developer: Reload With Extensions Disabled from the palette. That relaunches Antigravity with all extensions off. If the LSP behaves correctly in this state, the problem is somewhere in your extensions. From there, binary-search by enabling half at a time until you find the offender.
In my experience, certain combinations tend to misbehave:
- Multiple formatters installed simultaneously (Prettier, Black, etc. fighting each other)
- An old ESLint extension living next to the newer TypeScript ESLint integration
- Several AI completion extensions competing for the same suggestion slot
Extensions trade stability for convenience. It's worth doing a quarterly audit of what's enabled but unused.
Last-resort steps when nothing else works
If you've tried everything above and the LSP still doesn't cooperate, suspect a corrupted settings file. Antigravity stores user settings here:
- macOS:
~/Library/Application Support/Antigravity/User/ - Linux:
~/.config/Antigravity/User/ - Windows:
%APPDATA%\Antigravity\User\
Rename settings.json to something like settings.json.bak and relaunch with defaults. If the issue disappears, you can reintroduce your settings in chunks to identify which one was at fault.
If your project has a .antigravity/ folder at its root, it also stores workspace-specific state. Move that folder aside temporarily and reopen the project to separate workspace-level problems from user-level ones.
A repeatable recovery path
LSP issues hurt most because nothing tells you what's happening. Next time you hit one, start with Developer: Show Running Extensions to see what's actually alive, then work through restart → cache clear → extension isolation in that order.
If you want to go deeper, common editor errors in Antigravity covers the general-purpose failure modes I didn't get into here, when tab completion stops working focuses on autocomplete-specific symptoms, and troubleshooting a slow Antigravity is worth reading if performance itself is the issue.