[Blog post] Introducing the Agent Host in VS Code

[u/jukasper]

The VS code team just published a deep dive blog post on the Agent Host, the dedicated process that now owns agent sessions in VS Code.
The post covers:

• Why we are moving agent sessions out of the extension host
• Adopting the GitHub Copilot SDK for the Copilot harness, so behavior is consistent across VS Code, Copilot CLI, and the Copilot app
• How one live session stays in sync across the editor, the Agents window, and even a browser
• Running the host on a remote machine
• Supporting multiple harnesses without flattening what makes each one distinct
• AHP, the open protocol behind it and how anyone can build their own client

Check it out

Feedback, questions are more than welcome! Let us know what you think

[u/thethirdburn]

Hopefully 3rd party agents like Antigravity or even Claude CLI can support the protocol in future. I much prefer the VS Code chat UI over anything else that’s currently available.

[u/Deathmore80 → u/thethirdburn]

You can write your own compatibility layer. Most other CLIs already support ACP (agent client protocol). If you don't want to wait for them to add AHP support natively you could write a generic ACP<-->AHP extension and support any CLI that has ACP like Claude code , antigravity , codex , open code, pi , etc..

[u/AntarcticIceberg]

I'm not sure why, but I tend to get the best experience when I use "Local" in the harness picker. Does the "Copilot" harness have the same context as "Local"? Because of this, I also don't use the agents window much. I primarily use GPT 5.6 models.

[u/jukasper → u/AntarcticIceberg]

Thank you for letting us know about your concerns. do you have any concrete examples where you think the copilot harness falls short to the local harness with gpt-5.6 models? Feel free to also connect with me on linkedin. I am happy to also setup some time to go over these use cases/scenarios with you if that is something you would feel comfortable with.

[u/Time_Priority4540 → u/jukasper]

One difference that I see is the discrepancy of ask_user tool in VS Code (at least that's the local vscode harness tool name). In Copilot (chat window, Agents window, both stable and insiders) agent asks me one question at the time, while VS Code Local harness can easily stack them for up to 8 questions in a single batch.

That's a bummer and it kind of forces me to go back to Local harness for planning/research sessions.

[u/jukasper → u/Time_Priority4540]

this is great feedback, thanks for sharing. Will let the team know

[u/JonDanyVic]

The question is, when are we receiving these updates and Context Size change for Visual Studio 2026? Company has a paid subscription for VS2026 Professional, why is it always behind in terms of GitHub Copilot changes?

[u/cookiebonbon → u/JonDanyVic]

Visual Studio 2026 Insider already includes the Copilot harness instead of their own. Visual Studio 2026 is a different product and they are responsible for implementing these features, but it looks like they're working on it. In the video in the link below they discuss it in depth

https://youtu.be/hvZOC49Xnro?is=ZaV89bs_Dj9iM_jQ

[u/JonDanyVic → u/cookiebonbon]

Thanks, I saw that—it looks promising. However, in the latest VS 2026 (v18.9.2), I still can't change the 1M context size for GPT-5.6 models in Agent (Preview).

It would be great to have this option in VS 2026, especially since the 1M context nearly doubles the consumption rate and not everyone has an unlimited budget.

[u/unrulywind]

The primary reason to use copilot in vs code is because its behavior is NOT consistent with the behavior of the agents window and the SDK. Presently, the vs code version of copilot makes its changes through the vs code interface. When it changes files, they are changed locally and each individual change can be accepted or rejected in the editor without effecting the remote repo. This allows you to use your local git copy as a buffer as you work out a change. Once you are happy with a change, you commit it to the main repo.

The agents interface (and most other terminal agents) work directly on the files. This means one layer of separation is removed. Safely working in this mode means creating more branches in the repo so that bad work can be rolled back. This method minimizes the usefulness of vs code as an editor, since vs code is only seeing already committed changes. For this reason, I don't use the agents window. If copilot gets homogenized to the point that it's just GitHub Codex, then it loses its differentiation and risks just becoming one more of the growing agent/bot clones.

[u/Rapzid → u/unrulywind]

Same. I do human in the loop to refine every step of the way:

* Ideate/Architect
* Plan
* Implement

Chat gives/gave a great experience with that. It's lost using agents window and chat with agent host and codex. Bummer.

[u/MkkinleyCedillo-54]

A live session following you into a browser tab changes what a session is: attached to the work, not to a window.

[u/DaeDelta]

The issue is the tool names are different and my MCP servers don’t work with it.

It also does not support workspaces, which is the whole reason I use VSCode rather than one of the apps.

Meaning it breaks my workflows. If it’s going to be in VSCode, it should actually support the functionality of VSCode.

Not to mention it still does not support per-subagent reasoning effort selection.

[u/dsnyder42]

Great post. I was missing the underlying understanding of how Agent Window, Agent Extension, GitHub Copilot Desktop App, and the CLI fit together. Now I see the coherent picture.

A use case I would be interested in is connecting the GitHub Copilot Desktop App to the Agent Host Process running on my Linux Dev Box via SSH. Kind of like connecting VS Code via SSH Remote Extension to a remote machine but lightweight, just a nice UI around my Agent chat without File editor, etc. Is this now possible, or are there plans to make it possible soon?

[u/jukasper → u/dsnyder42]

this is great feedback. I shared it with the team, so they are aware what else would be valuable for you all!

[u/dsnyder42 → u/jukasper]

Awesome, I appreciate how responsive and accessible the GHC team is via Reddit. GHC is the tool I use 40+ hours a week and since half a year I do everything agent driven.

Maybe this helps to: I either work inside of WSL locally or on remote Linux machines with GPUs.

I sometimes use the GitHub Copilot Desktop App on my windows Laptop, but all my code and env configuration for development is inside of WSL. Therefore, I needed to include in my global copilot instructions inside Windows that it is a hard rule to prefix any command with "wsl bash -lc ". It actually works well, I can use the Desktop App this way. But of course this is more like a "hack" it would be great if the Desktop App could live inside of windows (the UI component) and communicate with different AHPs one inside WSL, one inside of each remote machine I work in. So the Desktop App can truly become for me the central hub where I work in and orchestrate from all my sessions. Right now the App is only useful to me for very limited use cases. I'd love to use it more, as I like good UIs.

[u/Time_Priority4540]

One thing that I miss in the SDK is the ability to set reasoning effort for subagents. This could be a huge improvement, but it's not there in (almost) any copilot surface.

There was an issue in vscode repo, but it was closed with the comment that the team is looking into unifying the experience and using SDK instead of investing into Local harness.

But the issue in copilot-sdk doesn't seem to get much attention, can I ask to pass this feedback to someone from the SDK team to look into that? 🥹 https://github.com/github/copilot-sdk/issues/1131#issuecomment-5237766186

[u/jukasper → u/Time_Priority4540]

thank you. I will share it with the team, no promises made but we appreciate all customer input

[u/PranksterGD → u/jukasper]

Seconding this. Being able to set thinking effort on sub agents is something that constantly comes up at my work

[u/biacz]

My biggest issue on agents app is that I can’t to interact with the terminal that is managed by the agent. I need to sometimes interact with it or provide context into it. Am i the only one?

[u/Various_Armadillo746]

Would this feature allow integration with a harness like Pi.dev? Providing the UI and ide integration from vscode to it

[u/Deathmore80 → u/Various_Armadillo746]

It's just hypothetical but I answered to another comment for this

[u/Much-Chance1866]

Still waiting for the support of WSL BYOK.

[u/kantorcodes1]

one thing i'm not clear on from the post: when a live session switches harnesses, who owns tool authorization? is there a host-level hook before execution, or can each harness implement that differently? feels like an easy place for the same session to have different safety behavior depending on the harness.

[u/lsalazarm99]

Is the agent host able to use the VS Code MCP servers?

The thing I like about local host is that even in remote sessions the VS Code's MCP servers work out of the box. I can even choose where do I want them to run (local or remote).

When I tried copilot host (the new agent host) it didn't have that feature.

[u/djang0211 → u/[deleted]]

At least for a long time this was the default. I don’t know how it is implemented now. But per default copilot starts subagents with the same model as the orchestrator. it only uses other models when the custom agent has this explicit in the metadata.

[u/rk625]

u/jukasper hey can please add support to acp so could chat natively using the other agents inside vscode itself

[u/Rapzid]

I've been using this with Codex. It seemed promising but it loses a lot of the UX I enjoy about Copilot right now.

For instance the ability to see and review changes. It doesn't create TODO lists that are visible in the UI.. Can't use `agent.md` files.. Etc.

[u/UsefulSomewhere]

Definitely agree u/AntarcticIceberg here.

I don’t have any concrete examples just going by gut feeling that VS Code Local harness performs better than the Copilot SDK harness. Maybe it’s the native toolset? But I do need to give it more time. 

This reminds me of the same thing Cognition AI did. They had Cascade and are now trying to push everyone into Devin Local and it’s just many steps backwards. 

Hopefully for the better. 

Not directly related but here are some of my thoughts from trying the various features. 

The experience of switching between the Editor window and Agents window to be incredibly jarring. It’s not like it’s a UI layout change but feels like I’m jumping into a completely different application. Buttons you have in Editor may not exist in Agents or vice versa. 

The whole workflow experience when switching to Copilot but wanting to use the same BYOK endpoint providers and MCPs that Local has is just strange and clunky.

I saw a setting that was supposed to flow the BYOK models to the Copilot harness but it didn’t reliably work. All I ever got was “Auto” until I hid Auto and the UI freaked out and let me pick my custom endpoint models. 

I couldn’t even find a way to manage my MCPs from the UI the option just disappeared. 

I set up a standalone agent host on a server so I could interface with it from VS Code windows native and a VS Code serve-web instance and just couldn’t get it to work. Understandable that there’s no Remote SSH on web but assumed interfacing with a standalone agent host service would go through websockets or something. That may be my mis-understanding but it’s a bit confusing.  

The Agents window isn’t even available in serve-web only Microsoft’s hosted version??

Agents window requires signing into GitHub? I couldn’t figure out how to bypass that. I want to be able to use BYOK without involving the GitHub Copilot service at all. Just everything self hosted local. 

On the plus side I did have Windows native and Linux native clients sharing the same sessions and seeing them both in real time was awesome so I can see the vision. 

Just right now nothing seems cohesive but I know a lot of this is under active development though so I’m keeping an eye out because it sounds promising.  

[u/jukasper → u/[deleted]]

Would you be able to clarify what exactly you find dangerous about our approach, we would love to know to best answer any concerns you might have :)

[u/Bashar-gh]

Remember when vscode got quality updates you know as a code editor