On July 1, 2026, the world's most popular code editor quietly turned on kernel-level sandboxing for every command your AI agent runs in the terminal. No keynote. No product blog post about it. Just a line buried in the VS Code 1.127 release notes: terminal commands on macOS and Linux now execute in an OS-level sandbox by default.
Browser tools for agents reached GA in the same release, and that got the headlines. The Agents window got groups and cost visibility, and that got the screenshots. The sandbox? It's the one that will break your workflows — and the one that matters most for the future of agent infrastructure.
Here's why: seven days earlier, I argued that the terminal ate the IDE because it gave AI agents unrestricted access to the system. The terminal won because it's the only surface where an agent can read any file, execute any shell command, and chain operations across dozens of steps without asking permission. That unrestricted access was the competitive advantage. It was the reason Claude Code, Codex CLI, and Gemini CLI displaced IDE extensions at the top of every benchmark.
VS Code 1.127 walks that back — not by removing terminal access, but by fencing it in. Every agent-run terminal command now executes inside a kernel-enforced sandbox with network access blocked and filesystem access restricted. Not a permission prompt. Actual isolation at the OS layer.
The terminal won. Now it's being contained.
What Actually Changed
Three things shipped in VS Code 1.127. Two got the press coverage. One will break things.
Browser tools for agents reached general availability. 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. Browser tools are enabled by default. No configuration needed.
The Agents window got organizational features. Agent groups for managing concurrent sessions, and real cost visibility — per-agent token spend, not just aggregate. This matters for teams, but it's incremental.
Terminal sandboxing flipped on by default for macOS and Linux. This is the change that most release roundups undersold. Starting with 1.127, agent-run terminal commands execute inside an OS-level sandbox with network access blocked and filesystem access restricted. It's kernel-enforced — not a prompt asking for permission, but actual isolation at the OS layer.
The setting is chat.agent.sandbox.enabled on macOS and Linux. Windows uses a separate setting (chat.agent.sandbox.enabledWindows) and a different runtime (MXC). And critically: sandboxing only applies in Default Approvals mode. If you've changed your approval mode to something more permissive, the sandbox is bypassed entirely.
That last detail is important. The sandbox is a default, not a mandate. But defaults shape behavior — and this default reframes the relationship between agents and the systems they run on.
The Retry Pattern Is the Real Innovation
Naive sandboxing would be a disaster. You can't run npm install with network access blocked. You can't git fetch without reaching a remote. A blanket sandbox would break every standard development workflow on the first attempt.
VS Code's solution is a three-tier retry cascade, and the design is worth studying because it's a blueprint for production agent security:
- First attempt: fully sandboxed. The command runs with network blocked and filesystem restricted. If it succeeds, you're done. If the command only touches local files — a linter, a test suite, a build — this works transparently.
- Second attempt: sandboxed with network enabled. If the first attempt fails due to network restrictions —
git fetch,npm install,curl— VS Code retries the command inside the sandbox but with network access enabled. The filesystem is still contained. - Third attempt: unsandboxed with user approval. If the sandboxed-with-network attempt also fails — because the command writes to system paths or hits unusual external endpoints — VS Code falls back to unsandboxed execution and prompts the user for approval.
Standard developer workflows survive this transparently. npm install succeeds on the second attempt. git push succeeds on the second attempt. npm test succeeds on the first. The developer never sees the retry logic unless something unusual happens.
Custom scripts are a different story. If your agent workflow runs shell commands against unusual external endpoints or writes to system paths, the retry logic may not cover it. The sandbox wall will hit on the first attempt, the network-enabled retry will fail, and you'll get an approval prompt. Test before you assume the defaults work for non-standard tooling.
This cascade — try contained, try contained-with-network, then escalate with human approval — is the right pattern. It treats the sandbox as the default execution environment and unsandboxed access as a deliberate, logged, human-authorized exception. That's the inversion. Unrestricted access used to be the default. Now containment is.
The Access-Control Inversion
Here's the contrarian read: the terminal didn't win because unrestricted access is good. It won because unrestricted access was available. Now that the terminal is the default agent surface, the infrastructure layer is reasserting control.
Think about what happened in the first half of 2026. Claude Code shipped nested sub-agents up to five levels deep. Codex CLI gained multi-agent coordination in Ultra mode. Terminal agents could spawn background processes, manage git workflows, run arbitrary shell commands, and chain operations without asking. The access model was: the agent has the same privileges as the developer. Full stop.
That model is a liability at production scale. An agent with unrestricted terminal access can exfiltrate source code, modify system configurations, install packages globally, or execute a destructive command — rm -rf with a typo'd path — that a human developer would catch but an autonomous loop won't. The terminal won the coding agent market because it enabled autonomy. But autonomy without containment is a security incident waiting to happen.
VS Code's sandbox default is the first major platform to formalize the correction. It doesn't eliminate terminal access — agents still run shell commands. But it establishes a principle: agent-run commands should be contained by default and escalated by exception. The unrestricted terminal was a phase. The sandboxed terminal is the destination.
This maps to a pattern from the server infrastructure world that most frontend and ML engineers haven't encountered: the principle of least privilege. Every production system — every Kubernetes pod, every Lambda function, every cloud VM — runs with the minimum permissions it needs. Network policies restrict egress. Filesystem access is scoped to a volume. The agent world has been operating without this principle. VS Code 1.127 imports it.
The July 1 Infrastructure Trifecta
The sandbox wasn't the only production default that landed on July 1. Two other releases hit the same day, and together they mark the moment agent infrastructure got its defaults.
Claude Code 2.1.198 shipped background agents by default. Subagents in Claude Code flipped from foreground to background execution: the main conversation keeps running while a subagent works, and Claude gets notified when it finishes so it can pick up the result mid-turn. More importantly, background agents in git worktrees now auto-commit, push the branch, and open a GitHub draft PR when they finish code work — no prompt, no pause. The draft flag is the safety boundary; merge authority stays with humans.
Two new Notification hook events — agent_needs_input and agent_completed — let you wire Slack or desktop alerts to the background agent lifecycle. The Explore agent, previously locked to Haiku, now inherits the main session's model (capped at Opus 4.8).
That's a production default for autonomy. Background execution, auto-commit, draft PRs, lifecycle hooks. The pattern you'd build by hand over three sprints is now npm install -g @anthropic-ai/claude-code.
Microsoft Foundry Agent Service reached general availability. Write your agent in whatever framework you want — Microsoft Agent Framework, LangChain, CrewAI — run azd deploy, and the infrastructure disappears. One command provisions a Foundry project, a model deployment, a container registry, Application Insights, and a managed identity. Your agent gets its own Entra ID, a dedicated endpoint, and scale-to-zero pricing.
That's a production default for deployment. No Kubernetes configs. No container registry management. No session state plumbing. The hosted agent wrapper handles identity, isolation, observability, and scaling.
Three releases, three layers, three defaults:
- Safety: VS Code sandboxing terminal commands by default
- Autonomy: Claude Code running background agents with auto-commit by default
- Deployment: Foundry deploying agents to managed infrastructure with one command
The era of "configure everything yourself" is ending. Agent infrastructure is getting opinions.
What This Means for Your Harness
If you've been building agent infrastructure — and the readers of Harness Engineering know this is the layer that matters — the sandbox default changes three things about how you design your system.
Design your harness for sandboxed execution. Your agent's tools need to work inside a restricted environment. This means: prefer local file operations over network calls. If a tool needs network access, design it so the sandbox retry logic covers it — standard HTTP, standard package managers, standard git operations. Don't build tools that require writing to system paths or hitting unusual endpoints. If you do, document the escalation path and make sure the user knows they'll see an approval prompt.
Treat sandbox failures as first-class events. Your harness should detect when a command hits the sandbox wall and handle it gracefully — either by retrying with the appropriate permissions or by informing the user that the operation requires escalation. Don't let sandbox failures surface as generic errors. They're a specific, recoverable condition, and your harness should treat them as such.
Stop assuming full system access. This is the hardest mental shift. For two years, the assumption has been that an agent with terminal access can do anything a developer can do. That's still technically true — the sandbox has escalation paths. But the default is now restricted access, and your harness should be designed to work within that default. If your agent can only function with unrestricted access, you've built a tool that fights the platform instead of working with it.
The Platform Choke Point
There's a strategic dimension here that's worth naming. VS Code is the most widely used code editor in the world — over 15 million monthly active developers. When VS Code makes sandboxing the default, it's not just a feature decision. It's a platform decision that shapes what every agent built on VS Code can do.
This creates a tension. The terminal agents that won the coding market — Claude Code, Codex CLI, Gemini CLI — are standalone tools. They run as independent processes and aren't subject to VS Code's sandbox. But they integrate with VS Code through extensions, and the terminal commands they run through VS Code's integrated terminal are subject to the sandbox.
The result is a split execution model. Commands the agent runs directly in its own process: unrestricted. Commands that flow through VS Code's terminal: sandboxed. For most workflows this is fine — the agent runs in its own process and uses VS Code as a rendering layer. But for workflows that depend on the integrated terminal, the sandbox is now in the loop.
Expect this pattern to spread. JetBrains shipped Junie CLI as a standalone terminal agent, but their IDEs will likely follow VS Code's lead on sandboxing. Cloud-based agent platforms — Replit, GitHub Codespaces, Google Cloud Workstations — already run agents in containers with network policies. The local IDE sandbox is the last surface where agents had unrestricted access to the developer's machine. That surface is closing.
What to Do This Week
If you're building or running agent workflows, three concrete steps:
Audit your agent's terminal commands for sandbox compatibility. Go through the shell commands your agent runs and classify each one: does it need network access? Does it write outside the workspace? Does it hit system paths? For each command that might break, verify the retry logic covers it. npm install, git fetch, curl — these are handled. Custom scripts that write to /usr/local or hit internal endpoints on non-standard ports are not. Fix those before your team updates to 1.127.
Update VS Code and test in Default Approvals mode. The sandbox only applies when you're in Default Approvals mode. If you've switched to a more permissive approval setting, the sandbox is bypassed — which means you're not getting the safety benefit. Update to 1.127, keep Default Approvals mode on, and run a typical agent workflow. Note which commands trigger approval prompts. Those are your sandbox compatibility gaps.
Review your enterprise agent policy. VS Code 1.127 ships a new JSON settings file that's the fastest path to policy delivery on non-MDM machines. If you're managing a team of developers using AI agents, this is how you enforce sandbox defaults across the org. The setting chat.agent.sandbox.enabled should be true in your policy. Document the escalation path so developers know when and how to request unsandboxed execution for legitimate use cases.
The Bigger Picture
The first half of 2026 was defined by access. Agents got terminal access, browser access, file system access, multi-agent orchestration access. The story was about removing constraints — giving models the tools to act autonomously on real systems. The terminal ate the IDE because the IDE constrained agents and the terminal didn't.
The second half of 2026 is being defined by containment. Not restriction — containment. The sandbox default doesn't prevent agents from doing their work. It ensures that the work happens inside a boundary, with a defined escalation path, and that exceptions are logged and human-approved. That's not a step backward. It's the maturation of the agent infrastructure layer.
The open-source Kite framework, released June 30 by beevr-labs, made this explicit in their design philosophy: production agents need circuit breakers, kill switches, and idempotency keyed on operation IDs so a retried action doesn't charge a customer twice. Their argument — that the model is about 10% of the work and the other 90% is tools, retries, guardrails, and evaluation — is the same argument VS Code 1.127 makes with its sandbox default. The infrastructure matters more than the model.
The teams that win the next phase of agent development won't be the ones with the most powerful models or the most unrestricted access. They'll be the ones who design harnesses that work inside boundaries — that treat the sandbox as a feature, not a constraint, and that build escalation paths that are transparent, logged, and safe.
The terminal won because it gave agents access. The sandbox default says: now let's make that access survivable.