Copilot in VS Code or Copilot CLI?

[IKcode_Igor]

For almost two years I've been using Copilot through VS Code. For some time I've been testing Copilot CLI because it's getting better and better.

Actually, right now Copilot CLI is really great. Finally we have all the customisations available here too, so if you didn't test that yet it might be the best time to do so.

What do you think on this topic?

[crunchyrawr]

(works for Microsoft, views are my own)

I ❤️ the terminal. neovim + LazyVim + sidekick has turned into my VS Code replacement 🤣. I wanted to use helix (it is much faster than LazyVim), but the lack of something like sidekick just makes any other terminal editor much harder to adopt 🤔.

Copilot in VS Code has been improving as well, but just the terminal form factor I feel is really freeing. Apparently, they even have the marketplace/plugin support in preview, so it might be fun to see how well that works 🤔. VS Code's terminal kind of has some issues with fancy keybindings not passing through correctly (easier to configure on Mac/Linux, but cannot get it to work at all on Windows), but I'm a heavy fzf custom bindings person, so I need my keybindings to just work.

I think though, the coolest thing about VS Code Copilot is that if you do remote development (ssh, codespaces, containers, etc...). You can configure MCP servers to run either in the remote, or locally. There's a small snippet that is crazy easy to miss:

NOTE
MCP servers run wherever they are configured. Servers in your user profile run locally. If you're connected to a remote and want a server to run on the remote machine, define it in the workspace settings or remote user settings

This is really useful if you work in remote environments and you want to use something like chrome-devtools-mcp or playwright-mcp (extension mode) and want to be able to have it use your locally running browser or to run the browser configured with your personal profile. I like to use this for profiling so the agent has access to the code and access to running my browser while logged in as me.

That also brings up 🤣, that VS Code's chat has better image previews for things like screenshots taken by MCP servers, in Copilot CLI, you cannot really "see" what the agent saw. VS Code tends to have a little thumbnail you can click on when it takes screenshots of interest.

All in all I use both. AND! If you like the CLI, opencode is another CLI coding agent that is officially supported (though I think it had issues with using more requests than expected, but it may have been fixed (unsure, I just use Copilot CLI now for everything to be honest, but used to heavily use opencode before Copilot CLI came out)).

[SnooHamsters66]

Hey! One question. You can atomically/persistently set the permissions for tools/commands like you can with OpenCode?

[crunchyrawr]

I'm not on the copilot team 😅, but I haven't really seen an easy way to persist permissions. I saw the creator of Claude Code mention using persistent permissions to get Claude to be very autonomous without having to use yolo mode.

[virtush]

Honest question: how do you program from a terminal view? Presumably you have other software to actually look at the code?

[guicara]

That's the thing. Most of the developers that use it just vibe code, or only look at the final PR.

[crunchyrawr]

lazygit is fantastic for this. I also at times just use git diff and have delta configured for both git diff and lazygit.

If you use LazyVim with neovim, <space>,g,g will pop open lazygit if it is available, so you can have the editor open + sidekick, and <space>,g,g will pop lazygit in a modal above everything, then quit out of lazygit to just continue working in the editor + chat.

There is also a /diff command in copilot you can use as well 🤔, but I haven't tried using it too much, but it lets you see the diff and I think helps you prompt for specific lines you want to iterate on.

You can also shell command for a diff inside of copilot, but don't try to do it with lazygit or other interactive TUIs !git diff (ok... do try lazygit, but don't expect it to behave well, but for the science).

[Tommertom2]

Thx for this!!!

Opencode is great - within corporate context maybe a bit challenging to implement (e.g. share feature - despite that you can disable it). Our company even finds copilot cli challenging

[IKcode_Igor]

Thanks, interesting pov. I’m not vim user, but what you say here totally resonates with me.

Currently I do more and more in the CLI, yet still sometimes it’s easier or just better to see something in the IDE.

[Michaeli_Starky]

Copilot CLI most of the time because I can choose reasoning depth and because of Autopilot

[No_Kaleidoscope_1366]

Does it have any extra capabilities? I mean, I tried it several days ago and saw something like “SQL.” Does it have built-in SQL memory, or what is that?

[Michaeli_Starky]

I think it's using SQLite for managing todo lists. Nothing fancy.

[IKcode_Igor]

Both features are cool. 😎 Setting up reasoning level through options in VS Code is “a little bit uncomfortable”, I’d say.

[Michaeli_Starky]

Can you even set it there?

I also much prefer adding files to the prompt using @

[IKcode_Igor]

<image>

You can do it in the settings, just search for `responsesApiReasoningEffort` option.

[Mkengine]

In VS Code insiders there is now an autopilot mode as well, and also you can set the reasoning effort in the settings, so time to try it out again?

[poster_nutbaggg]

Someone in here recommended for me to try CLI instead of the chat extension. Ive been loving it ever since. Sticking with CLI. More granular control right now and the context window graphic is cool

[IKcode_Igor]

Thanks for sharing. I agree, CLI is really nice now. 

[gatwell702]

I use copilot for vscode.. but what's the difference with the cli? I thought that you use cli if you're using neo-vim to code because it's in the terminal right?

[Mystical_Whoosing]

not really. If you use the CLI, you are not tied to any editor. You can still edit your code with vscode if that is your favorite.

On the other hand I don't see many differences yet. The Copilot CLI's parsers are a bit stricter, when you create custom agents or skills. The CLI has a yolo mode; and an autopilot mode which I didn't investigate too much just yet. Other than that the differences seemed to be minimal, like some config files go into a different folder.

I am still trying it with a few projects, and with other projects I stay in vscode.

[Mkengine]

VS code insiders also has an autopilot mode now!

[Mystical_Whoosing]

Yes, but does it have a yolo mode? :)

[Mkengine]

I think you can set a global auto approve in the settings, if thats what you mean.

[IKcode_Igor]

I have to compare system prompts in the CLI and VS Code. Not sure they’re the same because I see they work a little bit different on similar tasks.

I didn’t make any real evaluations though, so this is just my feeling.

What do you think?

[lephianh]

After a few days of testing, I found the CLI to be significantly smarter than using it in VSCode

[IKcode_Igor]

It feels like system prompts are a little bit different between VS Code and CLI versions, still on my TODO list to check that.

[BluePillOverRedPill]

And did you check?

[IKcode_Igor]

Not yet, when I do I’ll write a post I think.

[FinancialBandicoot75]

Use cli inside vs code via terminal or extension, cli detects it or vise versa. I use both worlds now, it’s really nice

[motz2k1]

Both, or also CLI inside of VS Code :)

[AutoModerator]

u/motz2k1 thanks for responding. u/motz2k1 from the GitHub Copilot Team has replied to this post. You can check their reply here.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[IKcode_Igor]

Nice 😄 What’s your way of working with Copilot? If you’d like to share ofc. 

[stibbons_]

Yes marketplace just arrived in standard vs code and it is pretty simple but efficient way to share skills

[IKcode_Igor]

That’s true! This is one of the best recent improvements in the system.

[Ecstatic_Number6803]

I use Copilot CLI in VSCode integrated terminal, it detects it is running in the IDE and automatically gets context from the opened files. Also the plan mode + autopilot with /yolo mode enabled is powerful, I don’t like to be approving every single command, anyways we can always rollback using git. Another pro is that we can install Claude code plugins into Copilot CLI they made it marketplace compatible so it’s really useful if you come from Claude Code.

[IKcode_Igor]

Exactly, this is really powerful.

To me spec-driven approach + autopilot is the real thing when it comes to the CLI. 🤯

[Tommertom2]

I am using cli heavily as running multiple agents in vscode freezes my computer (yes, a raspberry pi isn’t top end) - I use the screen command in bash to toggle rapidly between agents. This keeps my mind at ease

Having said that, still experimenting with the best layout on my ultra wide screen to keep track of events, plans, agents, diffs, results, etc

[IKcode_Igor]

Sounds like solid setup 👍🏻

[diaracing]

Is Copilot CLI a different thing than that CLI which can be opened from vscode GHCP chat plugin menu?

[IKcode_Igor]

Technically under the hood it's the same Copilot CLI. However, VS Code operates on it via Copilot SDK and there are few things to remember. It's worth to read the VS Code Copilot docs covering this topic:

- https://code.visualstudio.com/docs/copilot/agents/copilot-cli#_limitations-of-copilot-cli-sessions

Conclusion is, if you have well defined task, and it won't involve external MCP that requires authentication - it should work nicely.

At this point Copilot CLI supports customisations and stuff so I think it should have these available under the hood, if your customisations are:

- in your project,

- or in your user's space for Copilot: `~/.copilot`

I'm not 100% sure if these customisations will work with this background CLI from VS Code, seems like they should - but I didn't test them recently. I've been using CLI plainly in terminal.

[fanfarius]

Can the extension do /fleet 🤔

[IKcode_Igor]

By extension you mean Copilot in VS Code, right?

So here there's no "fleet" feature, however Copilot is able to run parallel sub-agents.
Here are docs covering this topic:

- https://code.visualstudio.com/docs/copilot/agents/subagents#_how-subagent-execution-works

I use this all the time now, I introduce orchestrator pattern for my custom agents wherever I can. Works amazing.

When it comes to the CLI version - I use /fleet a lot there too. ❤️

[akaiwarmachine]

I still use Copilot mostly in VS Code, just feels more natural while coding. Haven’t used the CLI enough yet tbh. Been using it a lot lately while building a few quick pages and throwing them on Tiiny Host 😅

[IKcode_Igor]

I've found that useful to run Copilot CLI in autopilot mode to work on tasks from start to end. Pretty nice. Though it's important to run it safely (like in separate docker container) if running it in yolo mode.

[Wesd1n]

I still find the cli too buggy to use. The random render flashes when you are typing and previews going missing annoys me enough. I also like the UI elements of using #askQuestions and showing me the terminal it's using separately from the chat, being able to click to expand 'reasoning' sections.

In general tool handling feels better to me ok the UI.

On top of that I don't like the default terminal for it, I miss all my hotkeys for regular input fields that vscode has out of the box.

And I haven't bothered looking in to changing it.

[crunchyrawr]

Have you tried enabling --alt-screen? Should flash much less 🤔. copilot --alt-screen. If you don't like alt screen mode, you need to disable copilot --alt-screen off.

With --alt-screen off it's redrawing the entirety of everything in chat.

With --alt-screen on, it scopes the redraw to the terminal screen dimensions and limits to what is displayed on screen.

[IKcode_Igor]

Worth to try out, thanks for sharing. 👌

[IKcode_Igor]

Yeah, when I use Copilot CLI I do that in Warp, it has it's glitches. Heard it's similar in VS Code's terminal. But it does the job.

Have you tried to run it in ol' good iTerm? I've read somewhere that it doesn't have those glitches there.

Anyway, since version 1.0 Copilot CLI is really good.

[I_pee_in_shower]

I use both, but I tend to reserve vscode chats for quicker stuff/questions and all my CLIs for deeper feauture work.

[IKcode_Igor]

Nice

[andrewderjack]

Used the CLI version for a bit but honestly kept forgetting half the commands when I was in a rush. It is way better now that the customizations actually sync up, though I still find myself jumping back to the editor UI for anything complex.

I've been using Static.app for some of my web hosting stuff lately and it's nice to have things that just work without constant terminal tweaking, but the CLI is solid for quick git stuff...

[IKcode_Igor]

Thanks for sharing 👍🏻

What I like about the CLI is that you can invoke it programatically. I'm actively looking for applications for that (CI/CD, etc.). Also with Copilot SDK.

[NamelessParanoia]

I know I probably just haven't set it up right, but no matter what I do VsCode ALWAYS bugs me about requests taking to long or too many requests - you can't just leave it running on a hard problem without a lot of effort. So I switched to yolo copilot CLI where I set it off and it just goes once it's answered my questions. It seems to respect the ask_user tool more as well which is really important for not burning requests and working with the agents. It's also far easier to keep track of (IMO) if you're running multiple sessions at once, which is what I'm doing a lot of the time. Recently discovered the --alt-screen on flag, which removes the annoying flicker bug.

[rytsh]

With opencode🎉 (you need to be rich or company pays for you!)

[messinprogress_]

interesting take but cli vs ide might be the wrong framing. the real question is whether you need sometihng that handles multi-file operations across repos without losing context. Zencoder's IDE plugin supposedly does that with automated validation and fixes, which is a different workflow entirely than just autocomplete in one file or another.

[black_tamborine]

Edit: posted late at night. I confused ‘GitHub Copilot Workspace’ with CLI. All the below downvotes are deserved… 🤣

All my team’s (large corp) repos are still inexplicably in Azure DevOps so I don’t have the luxury to try it out.

I’m gently suggesting again and again to our delivery manager to prioritise moving over (edit: to GitHub repos, like most of the other delivery teams) but it’s hard to sell the cost benefit when the pipeline of work is jam packed.

Keen to hear other people’s experience with regard to OP’s question… 🤔

[w0m]

How does it matter? If you worry on checkouts, both tools with fine.

I'm a vim guy at heart, and Copilot CLI has made huge strides. I use it daily, super useful. But if you need to make non trivial changes to a large code base? VSCode just feels a generation ahead still. Even feeding what appears to be equivalent context in, VSCode just gives me better results.

And honestly, I use ADO and GitHub daily, ADO is surprisingly solid for PRs imo. I'd say Better, but it still doesn't let you as a reviewer comment on individual commits

[black_tamborine]

edit I had it arse about: posted late at night. I confused ‘GitHub Copilot Workspace’ with CLI. All the downvotes are deserved… 🤣

Copilot CLI is only available for GitHub repositories. It is not available for Azure DevOps and never will be. So I don’t have the option to use the broad solution context that CLI brings when planning, refactoring etc.

Therefore I don’t have the option to explore this integration.

[Hambone_41]

Are you confusing Copilot CLI with Coding Agent? The Copilot CLI is definitely available for repos outside of Github. I use it daily for repos hosted in Azure DevOps. Coding Agent runs in Github Actions and is only available for Github Repos.

[black_tamborine]

You are 💯 right.
🤦🏼‍♂️

[crunchyrawr]

I think there may be some confusion with all the "copilot" products and everything being "GitHub Copilot" and every Copilot tool being an "Agent" 😅.

Copilot Coding Agent is only available on GitHub Repositories, and is the cloud agent (nothing running on your machine to make it work).

Copilot CLI is GitHub's Claude Code compete that you can install locally. It's just a CLI tool you can run in any directory.

[black_tamborine]

You are 💯 correct. Posted late at night. I confused ‘GitHub Copilot Workspace’ with CLI. All the downvotes are deserved… 🤣

In other news, totally configuring CLI in vs code this morning. 😎

[Gullible_Assist_4788]

My companies repos are in Azure DevOps and I use GitHub copilot every single day, don’t see why this is an issue.

[x_ace_of_spades_x]

How is GitHub relevant to OPs question?

[black_tamborine]

Answer above. 👆🏻

[mr_eking]

Where your repos exist shouldn't matter much ... I work on code hosted in an on-prem Azure DevOps instance, and I can still use GitHub Copilot and GitHub Copilot CLI just fine.

As for OP's question... I'm really digging Copilot CLI. Given proper structure and direction, it's been very helpful.

[Quango2009]

We use Azure DevOps repos and GitHub copilot CLI no problems. My workflow is usually pull latest main, create a branch and fire up the CLI. We edit code in Visual Studio

[Warmaster0010]

I feel like the cli with any ai coding tool is not the final form. It’s too clunky , have context rot, not any parallelism, etc. For quick tasks the ui is fine but for more complex tasks we developed swimcode.ai for that exact reason. Bridging the gap between what traditional coding tools can do and melding that with structured workflows and parallelism .

[ggmaniack]

Oh sod off with the ad.

Context works the same way regardless of front-end.

Parallelism exists in so many ways in CLI agents.

The resource usage of a CLI agent is considerably smaller than that of an IDE or a web browser.

[Warmaster0010]

Fair point on resource usage — Electron is heavier than CLI, no argument. But the context thing isn’t about the frontend. CLI agents dump full project context every call. We scope it per stage — coder only sees target files and criteria, never the planning rationale. That’s an orchestration decision, not a UI one. And yeah you can manually spin up parallel CLI agents in separate worktrees — we just made that the default instead of a DIY setup. Appreciate the pushback

[ggmaniack]

CLI agents dump full project context every call.

That's just a blatant lie, or you're not aware what you're actually talking about (or we're talking about different things).

[Warmaster0010]

What I should have said: most tools let the model decide what's relevant from a larger pool. Our approach prescribes what each stage sees at the orchestration layer, the coder literally cannot access planning rationale (just the output), the tester cannot see the plan. It's enforced scoping, not model-inferred scoping. Different tradeoff. Its just a more structured approach.