GitHub’s weekly Copilot release notes for 5 October include a quiet but important line: local sandboxing is now generally available in the Copilot CLI, the Copilot app and VS Code sessions that use Agent Host. GitHub says it restricts the agent’s access to files, networks and credentials, and that it comes at no extra cost.
The same release added a few smaller changes: Claude Haiku 5.5 for paid plans, side-by-side agent sessions in VS Code 1.141, and a /model command in the CLI that can discover models running locally through Ollama.
Why this matters outside the developer room
AI coding agents do not just suggest code any more. They run commands, edit files, install packages and talk to the network, often with little supervision. We have written about the other side of this: the zero-click flaws found in AI coding agents, and tools that can be extended in ways that run outside any safety boundary. Sandboxing is the standard answer. The agent works inside a fenced area and cannot read your keys, touch unrelated folders or call out to places it should not.
Until now, that fence was something a careful team had to build or enable for itself. Making it a supported, no-cost default-class feature lowers the bar. It does not remove the risk. A sandbox is only as good as its settings, and teams can still switch it off to make things faster.
What to ask your supplier
- Do your developers run AI agents inside a sandbox, and who controls the settings?
- Can an agent see production credentials, client data or signing keys?
- Which models and tools are approved, and is that written down?
These are ordinary due-diligence questions, and a good team answers them in one email. A vague answer tells you something.
So what
Speed from AI-assisted development is real, but so is the new attack surface. Choose a partner that treats agent safety as part of delivery, not an afterthought. That is how we approach AI-assisted development, and you can start a project if you want a straight answer on how we would run yours.