Parallel coding agents make sandbox policy and worktrees a design concern

What changed

GitHub's weekly Copilot roundup, dated October 9, 2026, moves its coding agents further toward parallel, sandboxed work. Three items stand out.

• Local sandboxing is generally available in Copilot CLI, the Copilot app, and VS Code sessions that use Agent Host. It limits what an agent can reach: files, networks and credentials. It is included with Copilot at no extra cost. The standalone GA post is dated October 7, and the roundup repeats it.
• VS Code 1.141 adds an Agents window that shows agent sessions side by side. You can arrange them in a grid to compare results or follow several tasks at once.
• A new "Open worktree cleanup" option in chat shows how much disk space inactive session worktrees use and lets you choose which ones to remove.

The same roundup adds Claude Haiku 5.5 to Copilot on the Pro, Pro+, Max, Business and Enterprise plans. It also lets the Copilot app use one GitHub account for the license and another for repositories.

Why it matters for builders

The default workflow is moving from one agent in one checkout to many agents, each in its own git worktree, each behind a restricted boundary. A free sandbox and a built-in grid view turn that pattern into the path most developers will be steered toward. Until now, teams mostly had to script it themselves.

This changes where the engineering problems sit. What an agent can touch is now a configuration surface, not something you get by being careful. A loose policy lets parallelism multiply the damage from one bad tool call. A tight policy makes agents fail in ways that look like model mistakes but are really permission denials.

The existence of a worktree cleanup feature is a signal in itself. Inactive worktrees pile up enough to show up as a disk problem, and they can also hold uncommitted state. Deleting the wrong one throws away work. Never deleting leaves stale branches and confusion about which result was accepted.

Side-by-side sessions also change review. Running several attempts at the same task is now cheap to set up, but the person comparing them is still the bottleneck. A grid of diffs is a place to read results, not a way to verify them.

What I would do with it

I would treat the parallel setup as a system with explicit boundaries and states rather than a UI convenience.

• Write down the sandbox boundary for each kind of task: which paths, hosts and credentials it needs. Start from deny, and review changes to that list like code.
• Record sandbox denials separately from task failures, so permission gaps are not mistaken for weak model output.
• Give every session worktree an owner and a status: open, accepted or rejected. Clean up only the rejected and merged ones, and confirm there are no uncommitted changes first. Abandoning work should be a decision, not a side effect of freeing disk space.
• Before launching parallel attempts, define the acceptance check: the tests that must pass and the surfaces that must be exercised. The grid is then for choosing among candidates that already passed, not for eyeballing.
• Start small, with two sessions on one repo and a task that has a clear test. Watch how often the sandbox blocks legitimate work before you widen the boundary or add more sessions.

Once agents run in parallel, the sandbox policy and the acceptance check you write before launch are the real design, and the side-by-side view is just where you read the results.

Sources

• GitHub Copilot weekly releases, October 5 - GitHub Changelog
• Local sandboxing for GitHub Copilot now generally available - GitHub Changelog