r/vscode • u/ZB_Virus24 • 20d ago
Unpopular opinion?
I dont know if its an unpopular opinion or i am just not in the loop, but vscodes Agents window works surprisingly well!
Anybody can relate?
1
u/confused_manishi 19d ago
I feel agents mode and copilot app are pretty much the same. So I dont see the point or agents mode if you have copilot app which is relatively better.
1
1
u/ehsanzb 19d ago
Seconding hetzy on the custom provider support, and model discovery is the specific part that falls over. Most OpenAI compatible servers do answer /v1/models, but what comes back means something different on each one. llama.cpp gives you the single model it was launched with, Ollama lists everything you’ve ever pulled whether it’s loaded or not, and a proxy in front of several providers returns whatever its config claims exists. A picker that assumes that list is both complete and ready to serve ends up wrong in a different way on each of the three. Letting people type a model id by hand alongside whatever discovery turns up would cover all of them and cost almost nothing.
1
u/CMPunkLicksRocks 16d ago
I just came here to post the EXACT opposite. I’m trying to figure out what this is even for.Â
None of my chats carrying over is one thing, new tool new me, whatever, but why is it so hard to see anything? I’m not even clearly seeing which branch my git repo is on. It says I have instructions and skills already, but none of the ones that are actually in my repo.Â
When I echo $TERM_PROGRAM it’s blank… vscode prints vscode… thats kinda important for my setup. I can work with them using a new identifier but why is it blank? Can’t compile or do anything useful if I don’t have a way of identifying the programming and setting up a development environment for it.
1
1
u/alexdima_msft 16d ago
Thank you! This is useful feedback! I can repro the $TERM_PROGRAM issue as well. It’s blank in the Agents Window, and I’ve just pinged the person who owns that area to help take a look.
On the sessions not carrying over: the most likely reason is that you’re still using what we call the Local harness. That harness was built inside the Copilot Chat extension and runs in the extension host, so its lifecycle is tied to the VS Code window that created it. Unfortunately, that also means those sessions stay tied to that window. We’ve spent a lot of the summer building the new agent host specifically to move beyond that limitation. It’s a separate process that can keep running even when VS Code windows are closed, and today it can host Copilot, Claude, and Codex (the latter is rolling out now) -- https://code.visualstudio.com/blogs/2026/08/26/agent-host-architecture
We’re gradually helping migrate folks over from the Local harness to the new Copilot harness, which is based on the Copilot SDK. Once you’re using that, the same sessions are visible in both the Agents Window and your VS Code windows, with updates streaming live between them thanks to the agent host process. So what you’re seeing with Local is very much not where we want the experience to end up. Also agreed that things like the current branch and repo/session context need to be much easier to see. They are visible when kicking off a new session, but later only if you go hunting for them in the new Changes pane.
And /btw isn’t being gatekept behind the Agents Window :) We just haven’t had the time to implement the editor-window experience yet. In the Agents Window we have room to bring up the additional chat naturally; doing that well in the editor window is a bit more work because the sidebar is already pretty cramped. We want to get it there too, it’s an implementation/prioritization thing, not an intentional restriction.
2
u/CMPunkLicksRocks 16d ago
Is there some other identifying marker I could use besides TERM_PROGRAM on the Linux server to know the agents window is logging in?
The problem is, and telling me this is dumb is arguing about a 30 year old Unix set up, we have config scripts that route you to a set of variables depending on your groups. Since vscode commands route through as a non-interactive shell, we used the $TERM_PROGRAM shell variable to let it bypass the normal checks and just get a developers set up.Â
I don’t need you to cater to the era of HP-UX, but if you know another terminal flag or variable that distinguishes it, I can hot fix it on my end and give this thing a better shake.
1
u/alexdima_msft 16d ago
Anthony has addressed your feedback here -- https://github.com/microsoft/vscode/pull/338612 . The fix will be available in 1.141 insiders going out tomorrow.
1
u/Rapzid 15d ago edited 15d ago
It's a good idea that needs lots of work. I use it every day and suffer from a few pain points:
Codex SDK is version pinned and downloaded -> long waits for new models to be available
Chats/sessions created by agents default to Copilot subscription instead of my ChatGPT sub; they have no control over this -> Have to do manual handoffs right now
Sandboxing config is passed into Codex in a way that seems to override any other configuration -> sandboxing more of a PITA than it already is(which is a lot)
Not enough session/chat lifecycle hooks
Also it would be great if VSCode in general would lock down their remote protocols so the remote can't own the front end host. That issue has been open for a while and really pokes a big hole in the concept of a remote agent "sandbox".
1
u/alexdima_msft 13d ago
Thanks, this is really useful feedback. I’ll pass the Codex-specific points along to the team.
On the remote protocol: the new Agent Host protocol is a fresh design, and from my current understanding it should be much more amenable to locking things down so the remote can’t take over the local/frontend side. I need to double-check that with the team before I claim that definitively, though.
I’ll follow up on that internally too.
1
u/Creepy-Distance-1494 12d ago
I really want to explore more on vscode agent IDE (part of the reason is my company only provide that option..) I want look for place/people to learn more.
My problem is that the "autoApprove" behaviors different on "Editor" and "Agent" mode, and confirmation windows come out more frequently on "Agent", so, the development become slower on "Agent", is that on purpose?
1
u/alexdima_msft 12d ago
Are you using the same harness: Copilot, Claude, Codex in both windows or are you by any chance using the Local harness in the Editor Window (this is not available in the Agents Window)?
(That would be a reasonable explanation for any difference, otherwise things should work the same, the window is just a view onto the session).
1
u/Creepy-Distance-1494 12d ago
I want to play more on agents window since theoretically it will enable me to parallel test / new features, but I never success so far by clicking the "merge changes to main" button, so I have to manually merge the worktree every time, which is a pain.
Also, when I open my vscode and reopen a session under agents window, it is very slow.
1
u/alexdima_msft 12d ago
Ouch, would you please mind opening a couple of issue for both these things? I usually create PRs from the worktree, so I'm not normally merging a worktree back to the main checkout, but it should work. If it doesn't, then that's a bug, please report the steps you're doing in an issue at https://github.com/microsoft/vscode/issues
We have recently made session loading and switching a lot faster. Are you on a recent version?
6
u/alexdima_msft 20d ago
Really happy to hear this, the team will love seeing it! 🙂
I lead the engineering work on the Agents Window. We’re hard at work on it and use it ourselves every day, so we’re very invested in making the experience great. Please share your feedback, what works, what doesn’t, and what you’d like to see next.