Reading the VS Code 1.121 release notes, I had the honest reaction that this might be the release where the boundaries of the editor moved the most they ever have. The summary in gihyo's article "VS Code 1.121 release. Mermaid diagrams and YAML frontmatter in Markdown preview ship by default, and remote agents arrive" reads short — "Mermaid standardised", "Remote agents added" — but re-read through the eyes of an Antigravity user, several deeper meanings rise to the surface.
I have been shipping iOS and Android apps as a solo developer since 2014. The wallpaper apps alone have crossed 50 million downloads, and these days I run four AI-focused tech blogs — including Antigravity Lab — in parallel. I switch between Antigravity and VS Code depending on the task, and movement in one always propagates to the other. This 1.121 release is not so much a story about the editor itself; it is a story about how the editor is beginning to step outside itself.
Remote Agents: Sessions That Survive Without the Editor
The first item worth pinning down is remote support in the Agents window. The Agents window that landed in preview in 1.120 now supports "Remote agents" — agent sessions running on a remote machine you reach via SSH or dev tunnels.
What this means inside an indie developer's life: until now, running an agent session in local VS Code meant the session closed when I closed the Mac in the evening. For long refactors or heavy multi-site content runs — "leave it running overnight, check in the morning" — I had to keep the local machine awake the whole time.
With Remote agents, an "agent host" process spins up on the remote side, hosting the agent loop that runs on top of the Copilot SDK. Even after the client (the local VS Code) disconnects, the session keeps running on the remote side. In my setup this becomes practical: drop code tunnel on a Mac mini at home, and from a MacBook Pro on the road I only connect the Agents window to peek in.
This is strictly different from the Remote Development extensions (editing remote sources via SSH or Codespaces). It is not about putting the entire editor environment on the other side; it is about putting only the long-running agent session on the other side. The editor boundary is splitting into two zones: a human workstation, and an agent runtime.
Agent Host Protocol (AHP): Session State as a Shared Resource
The communication backbone for Remote agents is a new open protocol called Agent Host Protocol (AHP). It is more than an implementation detail; it is significant as a design stance.
Under AHP, the agent host centrally manages the agent session's state and synchronises it to every connected client. State changes are ordered, so multiple clients can act on the same session without breaking consistency. My read: Agent Client Protocol (ACP) aligned "how editors and agents talk", whereas AHP takes responsibility for "the host holds session state, and synchronises it to multiple clients".
In practice that means agent sessions move closer to "a resource that lives on a server" than "a transient thing tied to a particular editor window". This lines up exactly with the direction Antigravity has been heading — multiple agents running in parallel, humans supervising them. Standardising this protocol on the VS Code side lays a foundation that derivative IDEs like Antigravity can ride directly.
Claude Agent's Auto Mode and Where to Place the Safety Valve
Claude Agent now exposes a preview "Auto" permission mode that runs operations without permission prompts. Enable github.copilot.chat.claudeAgent.allowAutoPermissions and Auto shows up in the permission-mode picker. Before each execution, a separate safety check blocks privilege escalation beyond the request, operations against unrecognised infrastructure, and behaviour traceable to malicious content.
Sitting next to Auto is "Bypass all permissions". The release notes call it "YOLO mode" outright, and even the setting key — allowDangerouslySkipPermissions — broadcasts the team's wariness.
Would I, as an indie developer, enable Auto mode? Conditionally yes. The conditions:
- The remote machine is in an isolated environment (a sandbox that does not touch production resources directly)
- Execution logs always reach me reliably
- The "ask me about these specifically" operations are spelled out on the Skill / instruction side
The third condition is what makes Auto practical. Pair it with the narrow allowed-tools pattern (the same idea I covered recently for the compile Skill in the Claude Lab context), and Auto becomes a knob you tune in code, not a binary you flip.
Model Selection and BYOK: Why Overrideable Utility Models Matter
A quieter but important change is that the "utility model" used for chat-related background tasks can now be overridden by the user. It covers chat session title generation, summarisation, commit message drafting, rename suggestions, prompt classification, intent detection — distinct from the model you use for the main chat response.
Two settings keys are involved: chat.utilityModel for general utility processing, and chat.utilitySmallModel for tasks suited to a smaller, faster model. By default VS Code resolves the former to the Copilot service's default model and the latter to gpt-4o-mini.
This matters when you want to split "heavy thinking goes to the latest model, lightweight classification goes to something cost-effective". Inside a single chat session, you can intentionally route the main response to a strong model and summarisation / classification to a cheaper, faster one. VS Code Insiders also previews a new "Custom Endpoint" BYOK provider — any Chat Completions, Responses, or Messages-compatible endpoint, configured from one place. Taken together, the editor stops being a tool that ties you fully to a single vendor and starts behaving like a hub for multiple models.
Integrated Browser and Terminal: Grading the Ground Around the Agent
The Integrated Browser now previews local HTML files without an extension. Right-click an HTML file in the explorer, or an open HTML editor tab, and pick "Open in Integrated Browser".
Adding elements from the browser into chat was also improved — click-and-drag selects multiple elements at once. For my indie-dev workflow, the realistic shape is "I want to hand the AI the DOM from this part of a production page on one of my four sites and discuss a refactor": select the elements and send them into Add Element to Chat. Until now that meant copying selectors out of DevTools by hand, with the few minutes of friction that implies.
On the terminal side, commands started by an agent now have the environment variable VSCODE_AGENT set. CLIs and scripts can check this variable and switch to machine-readable output, suppress progress animations, or skip interactive prompts. In my own auto-publishing pipeline, this opens the door to branches like "colour output when a human is driving, plain text when an agent is".
Add to that: commands that keep running in the background now show "Running <command> in background - Show", from which you can focus the relevant terminal. Background terminals created by chat agents are automatically disposed once the command completes. For an Antigravity-style workflow that runs many long-lived tasks, this alone moves practical usability up a notch or two.
Mermaid Built In, and YAML Frontmatter Display: Two Quiet Wins
Finally, the Markdown changes. Mermaid diagram preview, which used to live in the Marketplace as "Markdown Preview Mermaid Support", is now bundled as the built-in "Mermaid Markdown Features" extension. Markdown preview, notebook Markdown cells, and chat can all render mermaid fenced code blocks as diagrams.
A markdown.preview.frontMatter setting controls how YAML frontmatter is displayed, defaulting to table — frontmatter renders as a table at the top of the preview. codeBlock (render as YAML code block) and hide are also available.
It is a small change, but in a workflow like mine — generating and reviewing sixteen MDX files a day — having frontmatter formatted as a table at first glance raises the odds of catching a premium / level / category mix-up. Together with the Mermaid standardisation, this release nudges the editor one step further toward being a precise tool for "writing knowledge".
How an Antigravity User Reads This Release
Antigravity is an AI-native IDE built on a fork of VS Code's codebase. Anything that becomes standard upstream has a strong chance of arriving on the Antigravity side too, with some lag. What 1.121 shows is the editor shifting from "a tool that closes locally" to "a window through which multiple clients look in on agents that keep running on the other side".
I am reading this release partly as a hint about Antigravity's roadmap. As shared protocols like AHP take hold, single-vendor IDE differentiation thins out, and the battleground moves to operations — how you run agents on the other side, how you design Skills and permissions. For indie developers, that is a direction that broadens the available options. Thanks for reading.