When ESLint and TypeScript Squiggles Disappear in Antigravity: A 5-Point Diagnostic

"The red squiggles were there a minute ago, and now they're gone." If you spend enough time in Antigravity, you eventually meet this moment. The code is clearly broken, the Problems panel is empty, and saving the file does nothing. I lost half a day to this once after asking an agent to do a sweeping refactor, so I now keep a fixed order of checks pinned to my notes.

This piece is that checklist. Eight times out of ten, the first two steps solve it. The remaining three are the kind of trap that only shows up when you lean heavily on AI agents.

Triage the symptom in five seconds

"No squiggles" looks the same on the surface, but the cause depends on which kind of squiggle is missing. Before doing anything else, ask yourself which of these matches:

• Only TypeScript type errors are gone (assigning a string to number does nothing)
• Only ESLint warnings are gone (unused variables, stray console.log go unflagged)
• Both are gone
• Only one specific file is silent, while others behave normally

The fastest test is to type something deliberately broken — const x: number = "abc" — and watch what happens. If a squiggle appears, the problem is on the ESLint side. If nothing happens at all, your TypeScript checking is silent. If both produce nothing, the language services are likely down or your config is broken.

When only one file misbehaves, jump to point 4 below — that's almost always an include issue.

1. Restart the TypeScript Server

In my experience, this fixes about six out of ten cases. Antigravity inherits the VS Code command surface, so open the command palette (Cmd+Shift+P on macOS, Ctrl+Shift+P elsewhere) and run TypeScript: Restart TS Server.

Why does this help so often? The TS Server keeps an in-memory model of your project's types. After a long editing session — especially one where an AI agent rewrote dozens of files in a burst — that model can drift away from what's actually on disk. Restarting forces it to re-read files and sync up.

// .vscode/settings.json — settings that make TS Server more resilient
{
  // Helps prevent crashes on projects with thousands of files
  "typescript.tsserver.maxTsServerMemory": 4096,
  // Recommended when you use multi-root workspaces or pnpm workspaces
  "typescript.enablePromptUseWorkspaceTsdk": true,
  // Fallback when incremental diagnostics get out of sync
  "typescript.tsserver.experimental.enableProjectDiagnostics": false
}

Pushing maxTsServerMemory to 4096 MB makes large codebases noticeably more stable. On the flip side, if your machine is memory-constrained, lowering it to 2048 MB and accepting more frequent restarts can actually feel calmer day to day. I run 2048 on my laptop and 4096 on my desktop.

2. Open the ESLint extension Output

When ESLint goes silent specifically, the extension's log is the first place I look. Open the bottom panel, switch to the Output tab, and pick ESLint from the dropdown.

A red [Error] line almost always tells you the cause. The patterns I see most often are these three:

• Failed to load config xxx: a shared config you extends from is broken or its package is not installed. Usually solved by reinstalling dependencies.
• Parsing error: Cannot find module 'typescript': typical in monorepos where TypeScript lives in each package but not at the root. Hoist it, or install it in the package being linted.
• Rule '...' was not found: a leftover extends for a plugin you no longer use. Remove the line.

# Rebuild dependencies cleanly from the project root
rm -rf node_modules package-lock.json
npm install
# Then restart Antigravity, or run "Developer: Reload Window"

If your symptoms started right after upgrading to ESLint v9, the cause may be an incomplete migration to Flat Config. Having both .eslintrc.json and eslint.config.js in the same project tends to confuse the extension into emitting nothing. Pick one and remove the other.

3. Check the language indicator in the status bar

The little label in the lower-right of the editor (TypeScript JSX, etc.) is more useful than it looks. Click it and you can see exactly which language mode the current file is being treated as.

Occasionally you'll find the file is being read as Plain Text, which means no diagnostics at all. The two common reasons a .tsx file ends up as plain text are a stray // @ts-nocheck at the top of the file, or a missing entry in files.associations.

// .vscode/settings.json — declare language associations explicitly
{
  "files.associations": {
    "*.tsx": "typescriptreact",
    "*.ts": "typescript",
    "*.mdx": "mdx"
  }
}

Watch out for @ts-nocheck in particular. AI agents sometimes drop it in to "make the type errors go away" when they can't actually fix the underlying issue. Whenever a single file is silent, that comment is the first thing to check.

4. Audit include in tsconfig and eslintrc

This is the prime suspect when only one file is silent. Either include / exclude in tsconfig.json or ignorePatterns in your ESLint config has quietly excluded the file in question.

// tsconfig.json — the "exclude I forgot about" pattern
{
  "compilerOptions": { "strict": true },
  "include": ["src/**/*"],
  // The line below silently kills checking outside src
  "exclude": ["node_modules", "dist", "scripts/**"]
}

I've been bitten more than once by .ts files in scripts/ that simply weren't being type-checked. By default, a tsconfig with no include will check everything reachable from the root, but the moment you add the field, files outside it become invisible.

Whenever you create a new top-level directory, double-check both configs to confirm it's actually in scope.

5. Restore configs the agent edited via git

This is the boss fight. You ask an agent to "fix the type errors", and shortly after, diagnostics quietly stop appearing in unrelated files. The usual reason is that the agent flipped strict to false, deleted noImplicitAny, or removed an entry from your ESLint extends to make a stubborn error go away.

# Inspect recent edits to the relevant config files
git log --oneline -10 tsconfig.json .eslintrc.json eslint.config.js
# Roll them back to the previous commit
git checkout HEAD -- tsconfig.json .eslintrc.json

Agent-driven diffs are wonderful, but config files reward a stricter policy. I now treat tsconfig.*, .eslintrc*, and eslint.config.* as files that should always be reviewed by a human in their own pull request, separate from feature work.

While you're in this corner of the editor, my fix guide for an unresponsive language server in Antigravity, the Format-on-Save troubleshooting walkthrough, and the tab-completion fix round out the toolkit for diagnostics, formatting, and completion.

One step you can take today

Coding without squiggles is like riding a bike without a helmet — fine until it isn't. Start small: memorize the Cmd+Shift+P → TypeScript: Restart TS Server shortcut today. The next time the editor goes quiet on you, you'll get those guardrails back in two seconds instead of two hours.