Diagnosing and Fixing Breakpoints Not Hitting in Antigravity

You set up launch.json, drop a breakpoint, hit F5, and… your program runs straight through to the end. No pause, no hover panel, just a silent victory for the bug you were trying to catch. Few things drain a developer's energy faster than a debugger that refuses to break.

I've personally lost half a day to this on the eve of an app release. The cause turned out to be embarrassingly small, but the order I investigated it made the rabbit hole much deeper than it needed to be. So this guide walks through a top-down diagnostic order — including some Antigravity-specific quirks — that will get you to the real cause as quickly as possible.

A grey breakpoint is an "unbound" sign

In Antigravity (and the wider VS Code family), the appearance of a breakpoint already tells you half the story. Most people skip this glance, so make it the first habit you build.

• Solid red dot — bound to the running process. If execution doesn't stop here, you have a different problem (covered later).
• Hollow grey dot — not yet bound to a process (unverified). The IDE doesn't believe this source file matches the code it loaded.
• Outlined dot with a slash — the source map is missing or the file path doesn't line up.

In other words: if the breakpoint stays grey after the session starts, suspect paths and source maps. If it turns red but never pauses, suspect the actual code path or your conditional breakpoint expression. That two-tier judgment alone saves a lot of guessing — and it works the same way whether you're attaching to a Node process, a Python script, a Go binary, or a browser tab.

Source map mismatches — about 80% of cases

When breakpoints fail in TypeScript, Vue, Svelte, JSX, or any code that runs through Babel, SWC, or Webpack, the most common cause by far is a source map mismatch. From my own experience, this accounts for roughly 80% of the cases I've debugged.

// .antigravity/launch.json — temporary config to diagnose source maps
{
  "version": "0.2.0",
  "configurations": [
    {
      "name": "Debug Node TS (verify sourcemaps)",
      "type": "node",
      "request": "launch",
      "program": "${workspaceFolder}/dist/server.js",
      "preLaunchTask": "tsc: build",
      "outFiles": [
        "${workspaceFolder}/dist/**/*.js",
        "!**/node_modules/**"
      ],
      // Temporarily enables verbose sourcemap-resolution logs
      "trace": true,
      "sourceMaps": true
    }
  ]
}

Toggling "trace": true on for a single session floods the Debug Console with the mapping the debugger is actually using. If you see sourcemap not found or path mismatch in there, your investigation is essentially done.

The usual fix sequence is: confirm "sourceMap": true exists in tsconfig.json, then wipe build caches (dist/, .next/cache/, node_modules/.cache/) and rebuild from a clean slate. If that still doesn't work, double-check that the outFiles glob actually points at the directory your build emits to. A subtler trap is that some bundlers default to inline source maps in development and external maps in production — switching modes can quietly invalidate your outFiles configuration.

If you're working in a monorepo, the Antigravity monorepo management guide covers workspace resolution behavior that helps when designing those outFiles patterns.

Suspect cwd and program paths in launch.json

When source maps check out, the next layer to inspect is your working directory (cwd) and entry point (program).

{
  "name": "Debug Python — explicit cwd",
  "type": "debugpy",
  "request": "launch",
  "program": "${workspaceFolder}/src/main.py",
  // Without an explicit cwd, Antigravity uses the folder it was launched from,
  // which silently breaks relative imports and asset loading.
  "cwd": "${workspaceFolder}",
  "console": "integratedTerminal",
  "env": {
    "PYTHONPATH": "${workspaceFolder}/src"
  }
}

Setting cwd explicitly is the part I'd push for hardest. Personally, I've been bitten more than once by debugging a project while another window was technically the focused workspace — the relative program path resolved to a different file and I was happily debugging the wrong code. If you tend to keep multiple projects open at once, treat an explicit cwd as non-negotiable.

For Node.js, also remember that --inspect-brk versus --inspect changes whether you stop on the very first line. "It doesn't break on startup" sometimes means "you already flew past line 1." A related foot-gun: if you launch the program externally (say, via pnpm dev) and attach the debugger after the fact, the inspector port may have been reused by a previous run. Killing leftover processes before reattaching avoids the head-scratching "no breakpoints, no errors" silence.

Language-specific gotchas

Some of the worst time sinks aren't Antigravity's fault — they live in the runtime. Skim this list before you go deeper into IDE settings.

• TypeScript: When debugging through ts-node, you need --inspect and --require ts-node/register. If you're on tsx or swc-node, each has its own source map flags worth checking in their docs.
• Python: If pip install debugpy hasn't completed, or your virtualenv doesn't match the python path in launch.json, breakpoints will stay grey. Always cross-check which python (macOS/Linux) or where python (Windows) against launch.json.
• Go: An old delve build can't read the debug info modern Go compilers emit. Refresh with go install github.com/go-delve/delve/cmd/dlv@latest before doing anything else.
• Rust: Behavior diverges between lldb and cppvsdbg. And if you ran cargo build --release, optimizer-stripped line info will silently drop your breakpoints. Use a debug build for debugging — always.

If you're pairing this with LLM assistance, the workflow in the Antigravity AI debugging guide layers nicely on top of the diagnostic order above.

Three Antigravity-specific blind spots

Beyond the VS Code-family essentials, these three bite people specifically inside Antigravity. I've personally hit all three.

1. Agents holding the process: If an Antigravity agent is still running in the background, the debugger may fail to attach silently. Cancel the agent run, then press F5 again. This is especially easy to miss when an agent has finished generating output but is still streaming or waiting on a tool call.
2. AI-driven autosave: When an AI edit modifies your file just before you launch the debugger, your source map and emitted code go out of sync. Make Cmd/Ctrl + Shift + P → "Save All" your pre-debug ritual, and consider disabling auto-format on save for the file you're actively debugging.
3. Multi-folder workspace scope: If your workspace contains multiple folders, the status bar at the bottom-left shows which folder's launch.json is active. It's surprisingly common for the wrong one to be selected, especially after switching branches that touch the workspace structure.

The Antigravity custom rules and project config mastery article goes deeper into these per-project decisions if you want a more durable mental model.

When all else fails, fall back to console.log

If everything above checks out and the breakpoint still does nothing, drop down to the oldest tool in the box and verify the code is actually executing.

// src/main.ts — verifying execution path without a breakpoint
export async function handler(event: unknown) {
  console.log('🟢 handler invoked', { time: Date.now() });
  // No output here     = this function is never called
  // Output, no break    = source map issue
  // Output, no next log = an exception escaped before the next line
  const result = await process(event);
  console.log('🟢 handler returning', result);
  return result;
}

Tracing execution with console.log lets you tell apart "the breakpoint isn't binding" from "the code never ran in the first place." More often than I'd like to admit, the root cause has been that a test runner or a different entry point was the actual process running — the debugger session was simply executing a different path. The same pattern works for Python with print, for Go with log.Printf, and for the browser console; the lesson is to confirm the path before suspecting the tool.

Breakpoint problems span multiple layers, so randomly tweaking settings is the surest way to dig yourself in deeper. The next time the debugger goes silent on you, start with the breakpoint color, then walk down: source maps → cwd / program → language-specific runtime → Antigravity-specific scope. Keeping that order alone tends to cut the diagnosis time dramatically.