By VS Code 1.127, released July 1, ships three changes that push the editor further into autonomous agent territory: browser tools for agents graduate from preview to GA, the Agents window gets groups and real cost visibility, and terminal sandboxing flips on by default for macOS and Linux. That last one will quietly break workflows that hit it unprepared.
Browser Tools for Agents Are Now GA
After spending months in preview, agent browser tools are generally available and enabled by default in 1.127. Agents can now open pages in VS Code’s integrated browser, take screenshots, read console errors, click through UI, type, and navigate — all without an external MCP server. Per-site permissions work the way a browser should: when a page requests camera, location, or clipboard access, VS Code prompts once and remembers.
The practical upshot: the write-verify loop is closed. An agent can write a UI change, open the running app in the integrated browser, take a screenshot, read any console errors, and iterate — without a human relaying screenshots through chat. For web development workflows especially, this is the feature that makes agentic coding meaningfully faster rather than marginally faster.
Enterprise admins retain control. The ChatAgentNetworkFilter policy can restrict which domains agents are allowed to reach, and the feature can be disabled entirely. For teams that don’t want agents browsing arbitrary URLs, that guardrail now ships out of the box.
Agent Sessions Get Groups, Drag-Drop, and Per-Subagent Cost Tracking
The Agents window in 1.127 grows three useful additions. First, custom session groups: organize related sessions into named buckets, collapse group headers when focused on something specific, and kick off a new session directly within a group. Second, drag-and-drop reordering — select multiple sessions, move them as a block, pin the ones you need to keep visible.
Third, and the one that matters most if you’re watching your Copilot credit bill: subagent cost tracking. Since Copilot switched to AI credit billing on June 1, developers have been able to see total session costs. Version 1.126 added session-level cost tracking. Version 1.127 goes one level deeper — hover over a subagent section in a chat response to see exactly how many credits that delegated task consumed. When you’re running complex agentic workflows with multiple subagents doing parallel work, knowing which subagent is expensive is the difference between debugging costs and guessing.
There’s also a quality-of-life addition worth noting: chat input banners. When an agent session has an open pull request, a banner appears above the chat input showing CI check failures (“2 of 5 checks failed”) and incoming PR review comments. One click to hand failing checks back to the agent, one click to surface review comments — no context switch to GitHub required.
Terminal Sandboxing Is On by Default — Here’s What That Means for You
This is the default change that most release roundups will undersell. Starting with VS Code 1.127, agent-run terminal commands on macOS and Linux execute inside an OS-level sandbox with network access blocked and filesystem access restricted. It’s kernel-enforced — not just a prompt asking for permission, but actual isolation at the OS layer.
The reason this matters: agent terminal commands that previously ran silently will now hit a sandbox wall on first attempt. VS Code handles the common cases through retry logic — if a sandboxed command fails due to network restrictions (git fetch, npm install, curl), it retries with network access enabled inside the sandbox, then falls back to unsandboxed execution with user approval if that also fails. Standard developer workflows survive this transparently.
Custom scripts are a different story. If your agent workflow runs shell commands against unusual external endpoints or writes to system paths, test before you assume the retry logic covers it. The setting is chat.agent.sandbox.enabled on macOS/Linux. Sandboxing only applies in Default Approvals mode — changing your approval mode bypasses it. Windows uses a separate setting (chat.agent.sandbox.enabledWindows) and the MXC runtime. The full configuration reference is in the VS Code agent security documentation.
Sandboxing by default is the right call. It should have shipped this way earlier. As agent-run terminal commands become a standard part of VS Code workflows, kernel-level isolation is the appropriate security boundary — not a user prompt that developers click through reflexively.
Enterprise: Managed Settings Now Delivered via JSON File
VS Code’s managed Copilot settings now support a third delivery channel: a plain JSON file at well-known OS paths (/etc/github-copilot/managed-settings.json on Linux, /Library/Application Support/GitHubCopilot/managed-settings.json on macOS). This matters for organizations using Chef, Puppet, or Ansible — or whose developer machines aren’t enrolled in an MDM system. The file only takes effect when native MDM or account-based enterprise settings are absent. Enterprise admins also gained the ability to restrict extension installs to known marketplaces via the strictKnownMarketplaces setting. Full details in the enterprise AI settings documentation.
Update and Configure
VS Code 1.127 is available now at code.visualstudio.com. After updating: browser tools are on by default — no action needed unless you want to restrict domains. Check the sandbox settings if you run agent scripts with unusual network requirements. For enterprise teams, the new JSON settings file is the fastest path to policy delivery on non-MDM machines. The browser agent testing guide is the best starting point for teams looking to put the GA browser tools to work.
