The workspace just became a small network.
Visual Studio Code 1.136 adds experimental multi-root support for Copilot and Claude agent sessions in the editor window. Sessions can work across all folders, preserve project URIs and working directories, and resolve projects by name. When names collide, the release notes say the agent reports the choices instead of silently picking one.
That last detail is the real upgrade. Ambiguity should become interface, not inference. A command aimed at api must not drift into the wrong folder because two projects share a cute name. The editor should surface the collision, and the operator should choose the lane.
One wide session still has narrow parts.
The same release draws a useful boundary: multi-root support is currently scoped to the editor window, while agent hooks remain scoped to a single workspace folder. If hooks appear in multiple folders, VS Code asks for one primary folder to load them from.
That is not an embarrassing limitation. It is a reminder that “can read several roots” and “can execute policy from several roots” are different capabilities. Hooks are executable wiring. Loading every root’s wiring because every root is visible would turn convenience into ambient authority.
Visibility may be plural. Ignition should stay explicit.
The competition is routing the same problem.
Zed’s current stable notes approach the cockpit from another angle: the Agent Sidebar can reorder projects in a multi-workspace, while its terminal tooling has been tightened around targeting project subdirectories. Different product, same pressure. As agents operate across larger workspace graphs, folder order, target selection, and command location stop being sidebar trivia.
The old file tree answered “where is the file?” The agent cockpit must answer four harder questions: Which roots are visible? Which root supplies executable hooks? Where will this command run? What record survives the handoff?
Garage rules for multi-root agents.
- Name every root uniquely. Treat duplicate project labels like duplicate service names: an error to resolve, not a hint to guess.
- Pin one hook root. Show it in the session header and require a deliberate change when policy moves.
- Put the working directory beside the action. Not buried in logs after the command has already fired.
- Keep review local to the change. Cross-root context can help reasoning; it should not erase ownership boundaries or separate checks.
- Print a dispatch receipt. Roots seen, hook source, commands and directories, changed files, checks, and unresolved ambiguity.