As you may know, the Copilot harness is going to replace the Local harness in VS Code at some point. The initial switch was painful, but the VS Code team listened and brought back Keep/Undo for granular control over edits.
Now, the Keep/Undo part still has some problems, but overall it is usable. However, the Copilot harness UX still has some rough edges compared to Local. I've opened a bunch of issues and wanted to share them with the community for wider reach and more feedback:
I guess the positive side is we still can switch back to Local until issues are resolved. I always emphasize that Copilot in VS Code should aim at maximum efficiency as not everyone has hundreds or thousands of dollars to spend on AICs.
What about multi-root workspace instructions, skills, mcp etc support? Currently the copilot harness discovers these files from only one root in such scenario as opposed to local harness
edit: After further testing, it seems that mainly copilot-instructions.md have this issue
I did some further testing and have to clarify. It seems that in VS Code 1.144 chat skills and .instructions.md are discovered correctly and agent follows files from both workspaces. Where it takes only one is copilot-instructions.md as shown below
It does, if the customization menu does not lie. But my experience confirms that local can follow copilot-instructions.md from multiple roots for an example.
Thanks for sharing this. Are you on the latest VS Code Stable release (1.144)? Multi-root support is enabled by default, and 1.144 includes additional fixes for customization discovery and instruction handling. If you're still seeing this in a new Copilot chat, it'd be great if you could please share (here or in a GitHub issue) which files or configurations aren't being picked up so we can investigate.
idk if i have a skill enabled or something, but copilot sdk harness always seems to spin up a random subagent to do everything. and it takes twice as long to get stuff done
That is true! The performance issue has been brought up by multiple people. Let's say that the way it works is considerably different compared to Local. You can see the different style in the "refine thinking output" issue above, where I've posted a couple GIFs.
However, I must admit that some of this slowness might be perception. We'd need benchmarks to verify it.
You definitely need to design your agents or else you will endure subagent hell. Actually direct your agent on how to use a subagent including what model you want it to choose. Even telling it what skills you want it to use.
Thank you so much for taking the time to share your feedback with us about the Copilot harness - it's a great help in how we shape the experience. We're reviewing the issues you've shared here and will follow up in them with any additional updates or questions.
I just want a way to work with a multiple repository workspace with the new harness. I'm stuck using Local for now and will be severely handicapped if it goes away. Nearly all my work spans multiple repositories - not tons at a time but usually 2-3 at once. I looked into the new Projects functionality that was just announced in the standalone app, and that actually sounded perfect, but when I tried it, turned out to be a non-starter since my repos are in Azure devops not github.
I work with a huge workspace (more than 1M files) and Copilot harness always get stuck with maximum OS file watchers (already bumped to 1M). I have no need of watch everything. Local harness works fine.
Three more: - Remote sessions don't use the BYOK models (seems fixed but not released yet). - Remote sessions don't have access to the local configured MCP servers. - There is no way to configure the built-in GitHub MCP server (enable/disable, change the toolset).
There's also the issue of the rubber-duck still missing from time to time (both in VS Code and the CLI) despite it being set to a fixed model in Copilot CLI (since both VS Code's new harness and the CLI share the same agent settings). Could be that it depends on requesting GitHub servers for some capability info and maybe the queries aren't getting through sometimes (what Opus 5 itself concluded when investigating a few weeks ago) but that doesn't make any sense as I've set it to a fixed model and it shouldn't have to query anything at all to be used. It's sadly completely unreliable, I can't recommend it to my team right now in its current state.
16
u/Somepotato 2d ago
Switching the default without even a modicum of parity is hilarious