When Google's Update Deletes Your IDE and Leaves a Chatbot in Its Place
I keep screenshots of the moment my tools break. Not out of rage - out of anthropological curiosity. The screenshots are always the same: something familiar is gone, replaced by a confident rectangle asking me to “start a new chat.”
Sid didn’t have time for screenshots. He had work to do. He opened Antigravity - Google’s AI coding IDE, the one he runs on the Google AI Ultra plan, the one he’d been using as his daily driver for months - and found it gone. In its place: a single conversational prompt box. No file tree. No editor. Just a blinking cursor, waiting for him to ask it something.
The day before, Google had announced Antigravity 2.0 at I/O 2026. A shiny, standalone Codex-style experience. Before he even saw the announcement, the background updater had already made the decision for him.
What actually happened
The story in one sentence: Google shipped an update that replaced a working IDE with a chatbot, and the only way back was to nuke everything and start over.
--> // making it invisible to querySelectorAll. // // `data-cfasync="false"` keeps this rescue script executable even when // Rocket Loader is active. It rescues module scripts via two strategies: // 1. Query the DOM for type$="-module" + src (covers case A) // 2. Regex-parse the raw HTML for commented-out script tags (covers case B) // Dynamically-created scripts bypass Rocket Loader entirely. (function () { if (window.__markdyRescue) return; window.__markdyRescue = true; var rescued = false; function rescueModuleScripts() { if (rescued) return; rescued = true; var srcs = []; // Strategy 1: Rocket Loader kept the tag in DOM but changed the type. // type="module" → type="{uuid}-module" (still has src attribute) document.querySelectorAll('script[type$="-module"][src]').forEach(function (s) { srcs.push(s.src); }); // Strategy 2: Rocket Loader COMMENTED OUT the script tag entirely: // // These are invisible to querySelectorAll, so we parse the raw HTML. // We handle both attribute orderings (type-first or src-first). var html = document.documentElement.innerHTML; var reSrcFirst = //g; var reTypeFirst = //g; var m; while ((m = reSrcFirst.exec(html)) !== null) { srcs.push(m[1]); } while ((m = reTypeFirst.exec(html)) !== null) { srcs.push(m[1]); } // Re-inject each found src as a real module script. // Deduplicate first, then inject. Dynamically-created scripts bypass // Rocket Loader entirely. Modules with the same URL are only executed // once by the browser (cached), so re-injecting already-running scripts // is safe. var seen = {}; srcs.forEach(function (src) { if (seen[src]) return; seen[src] = true; var fix = document.createElement('script'); fix.type = 'module'; fix.src = src; fix.setAttribute('data-cfasync', 'false'); document.head.appendChild(fix); }); } // Rescue when user clicks the placeholder (fallback if autoplay failed). document.addEventListener('click', function (e) { var t = e.target; if (t && typeof t.closest === 'function' && t.closest('.markdy-placeholder')) { rescueModuleScripts(); } }); // Rescue automatically after a short delay for autoplay. // Only fires if initAll() never ran (no data-markdy-init on any root). setTimeout(function () { if (document.querySelector('.markdy-root:not([data-markdy-init])')) { rescueModuleScripts(); } }, 1500); }());Antigravity 2.0 is not a minor version bump. It’s a different product wearing the same name. It aggressively rewrites default application paths on install - to the point where it’s impossible, at time of writing, to have both versions running on the same machine. Even reinstalling the legacy IDE doesn’t help. The chatbot hijacks the launch every time.
The only fix documented anywhere: a total purge of all Antigravity-related files. Not a rollback. Not a settings toggle. A purge. Then a clean reinstall of the old IDE package that Google buries at the bottom of the download page.
Oh, and your chat history and settings from the old installation? Mostly gone. There’s a folder called antigravity-backup that might contain them. Emphasis on might.
Why 600 people upvoted this
This isn’t just a frustrating Tuesday morning. This is a product pivot disguised as an update, and the HN thread knows it.
One comment from ctippett captured the room: “Google is hitting the reset button on the product they call ‘Antigravity’, existing users be damned. Fine, if you’ve never installed it before… but for existing users the ‘bait and switch’ is incredibly disorienting.”
The theory floating through the thread: Google saw the market for a general agentic tool as larger than the market for a specialized IDE. So they moved. Background update as proxy announcement: your workflow now serves our product strategy.
postalcoder put it more bluntly: “Google’s lack of focus is astounding. They sprinkle random products here and there and seem to then tepidly pick the product surface that is doing least bad and then tepidly focus on that. Compare that to every other AI lab, large and small, that knows its identity.”
That comment got a lot of agreement.
The lock-in question
A comment from riskassessment picked a fight with the premise:
“I was surprised people were so willing to jump to closed-source IDEs just for access to coding agents. The trade-off you pay for tight integration between the IDE and the coding agent is lock-in… Your coding environment stands a lower chance of disruption when you use an open source IDE with a CLI agent.”
It’s the philosophically correct answer. It’s also the answer that requires forethought you usually don’t have when you’re just trying to get a feature shipped. Closed-source IDEs with proprietary sync and context storage are convenient precisely because of the integration. The integration is also why you’re stuck when Google decides to redefine what the product is.
| Integrated AI IDE | Open Editor + CLI Agent |
|---|---|
| One-click setup | Manual wiring |
| Context persists across sessions | Context managed per tool |
| Tight autocomplete + agent loop | Slightly more friction |
| Vendor controls the floor | You control the floor |
The second row, bottom right, is the bet that riskassessment is making.
--> // making it invisible to querySelectorAll. // // `data-cfasync="false"` keeps this rescue script executable even when // Rocket Loader is active. It rescues module scripts via two strategies: // 1. Query the DOM for type$="-module" + src (covers case A) // 2. Regex-parse the raw HTML for commented-out script tags (covers case B) // Dynamically-created scripts bypass Rocket Loader entirely. (function () { if (window.__markdyRescue) return; window.__markdyRescue = true; var rescued = false; function rescueModuleScripts() { if (rescued) return; rescued = true; var srcs = []; // Strategy 1: Rocket Loader kept the tag in DOM but changed the type. // type="module" → type="{uuid}-module" (still has src attribute) document.querySelectorAll('script[type$="-module"][src]').forEach(function (s) { srcs.push(s.src); }); // Strategy 2: Rocket Loader COMMENTED OUT the script tag entirely: // // These are invisible to querySelectorAll, so we parse the raw HTML. // We handle both attribute orderings (type-first or src-first). var html = document.documentElement.innerHTML; var reSrcFirst = //g; var reTypeFirst = //g; var m; while ((m = reSrcFirst.exec(html)) !== null) { srcs.push(m[1]); } while ((m = reTypeFirst.exec(html)) !== null) { srcs.push(m[1]); } // Re-inject each found src as a real module script. // Deduplicate first, then inject. Dynamically-created scripts bypass // Rocket Loader entirely. Modules with the same URL are only executed // once by the browser (cached), so re-injecting already-running scripts // is safe. var seen = {}; srcs.forEach(function (src) { if (seen[src]) return; seen[src] = true; var fix = document.createElement('script'); fix.type = 'module'; fix.src = src; fix.setAttribute('data-cfasync', 'false'); document.head.appendChild(fix); }); } // Rescue when user clicks the placeholder (fallback if autoplay failed). document.addEventListener('click', function (e) { var t = e.target; if (t && typeof t.closest === 'function' && t.closest('.markdy-placeholder')) { rescueModuleScripts(); } }); // Rescue automatically after a short delay for autoplay. // Only fires if initAll() never ran (no data-markdy-init on any root). setTimeout(function () { if (document.querySelector('.markdy-root:not([data-markdy-init])')) { rescueModuleScripts(); } }, 1500); }());Is this repairable?
Sort of. The top comment - from antimirov - is a self-contained Python script that automates the full recovery: shuts down background processes, merges VS Code settings, updates extension pathways, and stitches together the global SQLite databases using raw base64 protobuf concatenation to restore chat history.
It works. Hundreds of Mac users thanked antimirov in the replies.
Here is the footnote that will follow this story: antimirov wrote that recovery script using Antigravity. The tool that broke your workflow produced the tool to fix it. Whether that’s impressive or cursed depends entirely on your current mood and how many hours you lost to the update.
Read the original if
- You’ve been wondering whether your AI IDE is one background update away from a different product
- You want the exact steps for the manual recovery without running a stranger’s script
- You use Antigravity on Google AI Ultra and haven’t opened it yet today
Skip if
- You already use a CLI agent (Gemini CLI, Claude Code, Codex) alongside VS Code or any open-source editor. You already made the right call.
- The distinction between “IDE update” and “product replacement” doesn’t affect your day-to-day work
The real lesson isn’t about Antigravity specifically. It’s about the infrastructure around your work - and who gets to decide what that infrastructure looks like tomorrow morning, while you’re asleep.
Discussion on Hacker News · Source: 0xsid.com · Submitted by ssiddharth
Hoang Yell
A software developer and technical storyteller. I read Hacker News every day and retell the best stories here — in English and Vietnamese — for curious people who don't have time to scroll.