Copilot's Agents window and worktree cleanup: running many agent sessions

Running several coding agents at once is now a normal way to use GitHub Copilot. Each session gets its own branch and working copy, and developers switch between them as results come in. GitHub's weekly Copilot update of 9 October 2026 highlighted two small features in VS Code 1.141 that address the side effects: a grid for viewing agent sessions side by side, and a cleanup tool for the worktrees that inactive sessions leave on disk. Neither changes what an agent can do. Both say something about what parallel agent work costs, and where teams should put process around it.

The context: one worktree per session

The GitHub Copilot app documentation describes parallel workspaces as multiple isolated agent sessions running at the same time, "each with a dedicated git worktree and branch". A git worktree is a second working directory attached to the same repository, so each agent edits its own copy of the files without disturbing the others. VS Code's Agents window works with the same model, and VS Code 1.141 also picks up conversations started in Copilot CLI and the Copilot app as external sessions.

The VS Code 1.141 release notes, dated 7 October 2026, add:

• A session grid. Sessions in the Agents window can be dragged into horizontal or vertical splits, resized, and maximised one at a time, to compare results or follow several long tasks.
• Worktree cleanup. The command Chat: Open Worktree Cleanup lists inactive session worktrees with their size, filters them by how long they have been inactive, and removes the ones selected. Cleanup marks those sessions as done and deletes their worktrees; a session can be restored later, which recreates its worktree. Active, running, waiting-for-input and pinned sessions are protected.
• Automatic cleanup and prompts. The cleanup editor can be set to clean up sessions whose pull requests have merged, and a setting lets the Agents window suggest cleanup when inactive worktrees pile up.
• Session filters and nested-session status. Sessions can be filtered by where they run, which harness they use and which application created them, and nested sessions track their own unread state.

Analysis: what to make of it

Disk is the visible cost; review is the real one

A worktree is a full checkout. On a large repository, a dozen idle sessions can take a lot of disk, more again if each one installed dependencies or built artefacts. A cleanup tool is welcome, and protecting active and pinned sessions is a sensible default. But disk is the cost that shows up first, not the one that matters most. Every parallel session that produces a change also produces review work, and review does not parallelise the way agent sessions do. A grid makes it easier to watch four agents; it does not make it easier to review four diffs properly. Firm-level research points the same way: see AI agents write more code; review still sets how much software ships.

Cleanup by merge state is a useful signal

Tying automatic cleanup to merged pull requests is a reasonable rule: once the change is in, the worktree has served its purpose. The opposite case deserves attention. Sessions whose work was never merged, or never opened as a pull request, are where abandoned changes and half-finished experiments accumulate. Looking at that list now and then shows how much agent output is being thrown away, which is useful when judging whether parallel sessions pay off.

Restoring a session is not restoring its state

The release notes say a cleaned-up session can be restored, which recreates its worktree. They do not say that uncommitted changes or build output come back. Teams should assume anything not committed to the session's branch is gone after cleanup, and set the habit accordingly.

This is ergonomics, not a security control

Worktrees separate files between sessions; they do not isolate one agent from another or from the machine. Every session still runs with whatever access its harness and sandbox allow. VS Code 1.141 also adds sandboxing for the Copilot agent host, which is a separate setting and a separate decision.

What it means for engineering and security leaders

Parallel sessions change the shape of the work more than its speed. One developer can start more changes than before; the team's ability to review, test and merge them stays roughly where it was. The useful questions are about flow:

• How many agent-authored pull requests are open at once, and how long do they wait for review?
• What share of sessions ends in a merged change, and what share is cleaned up unmerged?
• Does the cost per merged change, in tokens and in reviewer time, justify running sessions in parallel for a given kind of task?

The answers differ by task. Mechanical, well-specified changes suit parallel sessions; changes that need design judgement usually do not. The harness also matters: the same model can cost very differently depending on the agent around it, as covered in the harness sets the bill.

Practical takeaways for this week

• Update VS Code to 1.141 or later if your developers use the Agents window, and try Chat: Open Worktree Cleanup on a busy machine to see how much space idle sessions use.
• Turn on automatic cleanup for sessions with merged pull requests, and commit or push anything worth keeping before a manual cleanup.
• Set a soft limit on concurrent agent sessions per developer, based on review capacity rather than machine capacity.
• Track open agent-authored pull requests and their review wait time alongside other delivery measures.
• Treat sandboxing as its own decision, configured and, where supported, enforced through managed settings.

Where SpanDock fits

Measuring whether parallel sessions pay off needs per-session numbers. In SpanDock, the Activity page's Sessions tab lists each AI tool session with its project, duration, calls, tokens, cost and models, as described in getting started, and the data can be forwarded to another observability tool through destinations (several at once on the Standard plan and up). How AI coding tools report sessions over OpenTelemetry is covered in observing AI coding tools.