Background Agents powered by Copilot CLI is a confusing design decision

[TylerLeonhardt]

@rebornix asked me to write something up here because I have a real use case that is pained by the current design of Background Agents.

Myself and others on the team use the following Custom Agent

https://github.com/microsoft/vscode/blob/fd7fb44d73a151ef18aad2277c4c6113c91ff06f/.github/agents/data.md

which does a great job at answering questions backed by VS Code telemetry data. The goal of this custom agent is to allow me to not think about Kusto syntax, and just let the model be my query machine.
It has brought data into the inner loop of my development since natural language is so much easier than Kusto queries.

Importantly, I don’t care to watch it work ... I just care about the result. Take my question, run along and query kusto, and come back with a data-backed answer. The impression I get from “Background Agents in VS Code” would be that they are the perfect solution to this, but due to the architecture, they don’t work at all.

Why?

• This custom agent depends on Azure MCP Server, which is an Extension contributed MCP Server
• When a user doesn't have that extension installed, we use the vscode extensions tool to show the extension that the user needs to install

These are the examples as to why this particular scenario doesn't work in Background Agents

What I really want

I want VS Code Agent-powered Background Agents. I want everything to work as it does in the "local" case, but in the background... perhaps with the ability to either run it in the current workspace or in a worktree.

The fact that Background Agents & Local Agents, both running on the same machine where VS Code is installed, can't behave the same way makes me so confused by this experience and the platform we are building... A lot of work is being put into Background Agents and me not being able to take advantage of this VS Code feature because I'm using a VS Code feature that doesn't mix with it is disappointing.

At the very least

I would feel way better about this if we were upfront of this being powered by Copilot CLI. I might not have the same expectations as I do.

Current workaround

Don't use Background Agents and instead rely on "background session" behavior where I ask a question and then hit new chat.

[TylerLeonhardt]

The other scenario I have that also doesn't work right now is the Demonstrate custom agent which, tbf, is mostly to be run in CI under copilot-cli... but there is no reason I couldn't also use this in VS Code local agent while I am developing the custom agent.

https://github.com/microsoft/vscode/blob/a8f71903a6e3dd3f63831d3e1501c3107540ff11/.github/agents/demonstrate.md

It can work in both, but there are differences in how these harness handle MCP servers:

• VS Code supports everything, and the important one for this scenario, it supports tool discovery (running a tool which causes other tools to be registered) something that was critical for this MCP Server as it exposes 50+ tools.
• Copilot CLI does not support this
• I think I maybe tried background agents once, and it didn't work at the time (maybe there was no MCP support at that time or something, I don't remember)

To work around this, the VS Code agent gets to use the mcp.json at the workspace:
https://github.com/microsoft/vscode/blob/a8f71903a6e3dd3f63831d3e1501c3107540ff11/.vscode/mcp.json#L1-L13

While the copilot cli agent has to be run special using this script:
https://github.com/microsoft/vscode/blob/a8f71903a6e3dd3f63831d3e1501c3107540ff11/test/mcp/scripts/start-stdio.sh#L2-L8 (the --autostart param which tells the mcp server not to use tool discovery)

These differences just cause me pain and don't sell me on this being a cohesive platform.

[katriendg]

Having tested this concept out somewhat, I believe these points are very valid and would like to share a few elements that add to your issue description.

When we look at the new features of running agent sessions - local, background and cloud - the main difference and advantage that triggers me to use the background agent is this ability that the background agent can run and do its work in the git worktree in addition to the workspace, so I can keep on running multiple (non-conflicting) local agent sessions in my work branch and not be concerned with changes that may conflict.
Other than this, I have yet to find a reason to kick off a background agent when using same workspace, since it is so similar to running a local agent session in parallel with another local session, and the local agent session gives me access to all tools.

Without the feature to leverage VS Code and MCP tools, the current background agent feature is very limited and confusing.

Potential design approach: enhance the ability for local agent to run in a worktree mode, leveraging any of the custom agents and tools (including tool approval which is expected). This sort of becomes the background agent mode, keep this name or using another name like 'local agent in worktree' or similar.

[bpasero]

I am sharing Tylers sentiment and would love to dogfood local sessions with worktree support to see how much I can get out of it vs. background sessions that today are quite limited. That doesn't mean we shouldn't invest more into background sessions because I think over time they will become more autonomous and more isolated.

[Tyriar]

👍 my perspective is that I've invested into getting good at regular agent mode in vscode, I shouldn't need to learn the nuances of a new tool just to use the worktree support. I went from separate clones to worktrees recently, but it's still cumbersome to manage as I can see the worktrees in the SCM panel, but I need to manage the chats in totally separate windows.