Most engineers learned Visual Studio through a mouse-driven workflow — New Project — open a project, click through a few dialogs, press F5. The GitHub Copilot CLI inverts that workflow: you describe the desired outcome in plain English (or any other language Copilot supports), and the agent scaffolds the project, drives MSBuild, resolves its own compiler errors, and explains the result. By the way: this style of working — you describe what you want and the AI does the actual programming and takes care of the rest — is also known as Vibe Coding. For Microsoft FTEs, this translates into measurably faster proofs of concept for customer escalations, reproduction builds, and internal tooling. Engineers outside Microsoft benefit in exactly the same way, as long as their organization — or their personal subscription — provides the corresponding Copilot entitlement.
This article documents the setup and workflow recommended for engineers onboarding to the CLI. The guidance is deliberately opinionated, assumes a clean Windows 11 installation, and has been verified end-to-end against the current Visual Studio 2026 Community (18.6.2) and Copilot CLI 1.0.56.
Why use the CLI at all?
Copilot is available inside Visual Studio, inside VS Code, in the browser, and on the command line. These front-ends share the same underlying model, but the user experiences differ significantly.
The CLI is the preferred choice in the following scenarios:
- You want a single tool that drives the whole machine — installer flags, MSBuild, winget, certificates, registry, even vswhere — rather than only the files open in an editor.
- You are working on a throwaway repro for a customer issue, where opening the full IDE is disproportionate.
- You want repeatable, scriptable workflows. The CLI accepts instructions, plans and prompts that can be checked in, reviewed, and shared with the rest of your team.
- You need to build small tools or short projects without deep programming expertise.
Prerequisites
- Windows 11 (or Windows 10 22H2) with administrator rights for the install step.
- Microsoft FTE GitHub account linked through the Open Source @ Microsoft portal and a Copilot Business or Enterprise seat assigned by your org. Engineers at other organizations use whichever GitHub identity their employer has assigned a Copilot seat to; individuals can substitute a personal GitHub account that holds a Copilot Pro or Pro+ subscription.
- A modern terminal — Windows Terminal with PowerShell 7 is the supported combination.
Note Everything in this guide is built on supported, GA components. Nothing here requires private previews, MSIT exceptions, or non-public flags. If your tenant has additional Conditional Access policies, you may be prompted for MFA the first time you sign in.
Recommended: Run it all in a virtual machine
Before installing anything, an important recommendation: don't run the agent on your primary, company-managed laptop. The CLI — especially with --yolo — has full read, write and execute access to any directory you have trusted. A well-intentioned prompt such as "clean up the temp files in my projects folder" may delete production work if it is pointed at the wrong root. Compliance tooling, OneDrive Known Folder Move, and on-access antivirus on the corporate image also routinely conflict with build outputs and cause agent runs to fail in opaque ways.
The safe, repeatable pattern is to host Visual Studio 2026 and the Copilot CLI inside an isolated environment that can be snapshotted, reset, or discarded. The following options are all suitable:
- A Microsoft Dev Box (preferred — already domain-joined, already monitored, and easily recreated from an image).
- An Azure VM in your sponsored subscription, ideally with the Visual Studio image from the Marketplace.
- A local Hyper-V or WSL2/Windows Sandbox-based Windows 11 VM for offline experimentation.
Important Treat the VM as ephemeral. Retain customer artifacts, screenshots and reproductions only within the VM (or in a dedicated OneDrive/SharePoint location outside the trusted Copilot directory). If something goes wrong, you reset the VM — not your corporate laptop.
Setting up the workspace
Select a workspace folder before performing any other step, and observe two rules:
- Use a local path under your profile.
- Do not place it on OneDrive, Known Folders Move, or any other sync root.
The rationale is mundane but consequential: the Copilot agent writes files, MSBuild writes obj\ and bin\, and OneDrive's file-system filter will conflict with all of them. You will observe ghost lock files, partially rewritten .cs files, and "the process cannot access the file" errors that are extremely difficult to diagnose.
# Recommended workspace root
mkdir "$env:USERPROFILE\AppData\Local\Projects"
cd "$env:USERPROFILE\AppData\Local\Projects"
Warning Also avoid %TEMP% for build output. MSBuild emits warning MSB8029, and cleanup tasks in some scheduled jobs may delete your intermediates mid-build.
Installing the Copilot CLI
Open an elevated PowerShell window — the package needs to register PowerShell 7 as a dependency on first run:
winget install GitHub.Copilot
Winget downloads the CLI itself (currently 1.0.56) and, on a fresh installation, also installs PowerShell 7 as a dependency. Once the installation completes, the elevated shell can be closed — do not run Copilot as administrator for day-to-day work.
Confirm the install in a normal (non-elevated) terminal:
copilot --version
Installing Visual Studio 2026 Community
The CLI does not require Visual Studio — it strictly requires only MSBuild and the appropriate toolchain. However, the Community edition is the most straightforward way to obtain a known-good, fully Microsoft-signed installation of MSBuild 18.6.x, the MSVC v145 toolset, and the Windows 10/11 SDK, all in a single step. Select the variant that matches your target workload:
Variant A — C# only (≈ 2.4 GB)
winget install --id Microsoft.VisualStudio.Community -e --source winget `
--override "--add Microsoft.VisualStudio.Workload.ManagedDesktop \
--add Microsoft.Net.Component.4.8.1.SDK \
--add Microsoft.Net.Component.4.8.1.TargetingPack \
--add Microsoft.VisualStudio.Component.CSharp \
--includeRecommended --passive --norestart"
Variant B — C# + native C++ + C++/CLI (≈ 4.3 GB)
winget install --id Microsoft.VisualStudio.Community -e --source winget `
--override "--add Microsoft.VisualStudio.Workload.ManagedDesktop \
--add Microsoft.VisualStudio.Workload.NativeDesktop \
--add Microsoft.VisualStudio.Component.VC.CLI.Support \
--add Microsoft.Net.Component.4.8.1.SDK \
--add Microsoft.Net.Component.4.8.1.TargetingPack \
--add Microsoft.VisualStudio.Component.CSharp \
--includeRecommended --passive --norestart"
A brief description of each component:
|
Component
|
Why it's there
|
|
Workload.ManagedDesktop
|
Brings WPF, WinForms, the .NET Framework 4.8.1 target packs and Roslyn analyzers.
|
|
Workload.NativeDesktop
|
Native C++ with the MSVC v145 toolset, Windows 10/11 SDK 10.0.26100, ATL/MFC if you add them.
|
|
VC.CLI.Support
|
The "C++/CLI support" component. Without it, anything with <CLRSupport>true</CLRSupport> fails to compile.
|
|
Net.Component.4.8.1.*
|
SDK + targeting pack for the .NET Framework 4.8.1 surface that ships with Windows.
|
As a Microsoft FTE you have access to Visual Studio Proffessional or Visual Studio Enterprise. If you already have installed a different version of Visual Studio, you don't need to install 2026 Community.
Important Visual Studio 2026 ships the new v145 platform toolset, not v143. Old .vcxproj files copied in from VS 2022 must be retargeted, otherwise the build fails with MSB8020 — build tools for v143 cannot be found. Copilot can perform this retargeting on request, but the requirement must be stated explicitly.
First launch & sign-in
Change into your project folder and start Copilot. The default invocation recommended for day-to-day FTE work is:
cd "$env:USERPROFILE\AppData\Local\Projects\Repro-12345"
copilot --yolo --no-ask-user --model "claude-opus-4.8" --effort "medium"
The flags are defined as follows:
|
Flag
|
What it does
|
|
--yolo
|
Pre-approves tool execution, file writes and shell commands for the session. Equivalent to --allow-all-tools --allow-all-paths --allow-all-urls. Use only within trusted folders.
|
|
--no-ask-user
|
Suppresses the interactive confirmation prompts mid-task — the agent continues without interruption.
|
|
--model
|
Pins a specific model. Useful when determinism across a team is required or when comparing runs. To see, which model best fits your needs, take a look at the model comparison at https://docs.github.com/en/copilot/reference/ai-models/model-comparison
|
|
--effort
|
low, medium, or high. Higher values allocate more reasoning tokens per turn — slower, but advantageous for complex build errors and architectural work.
|
Copilot first prompts you to confirm that you trust the current folder. Select "Yes, and remember this folder for future sessions" only for workspaces you control. Then run /login if you have not yet authenticated — this opens a browser tab in which you sign in with your FTE GitHub identity.
Sign in to Copilot on an unmanaged / non-FTE-domain machine
The Copilot CLI signs in with a GitHub identity, not directly with your Microsoft corporate account. On a company-managed device this is transparent — your Enterprise Managed User (EMU) account <alias>_microsoft is accepted without further action.
On a fresh VM, an Azure VM image, or any other unmanaged device, /login will refuse the EMU account unless you have explicitly linked a personal GitHub account to your EMU and granted it Copilot entitlement. The same pattern holds for engineers at other enterprises: they sign in with the GitHub identity their organization has provisioned with a Copilot seat. Individuals on a Copilot Pro or Pro+ plan can sign in directly with their personal GitHub handle, without any linking step.
For Microsoft FTEs, linking is performed once, from any browser, at:
https://aka.ms/copilot
Sign in with your Microsoft corporate account, link your personal GitHub handle (creating one first if necessary), and accept the prompts. When complete, the page should display every checkbox in green:
![]()
A correctly linked account ataka.ms/copilot
. The first green check confirms Copilot on the EMU account; the bottom green check is the one that is relevant for unmanaged VMs — "GitHub Copilot enabled for your personal GitHub account for use everywhere", granted through your MicrosoftCopilot organization membership.
Once that bottom row is green, run copilot inside your VM, use /login, and select your personal GitHub handle when the browser device-code flow opens. From that point onward, every CLI session in that VM uses your linked personal identity, your Copilot entitlement follows you, and your activity remains attributable through the MicrosoftCopilot organization for audit purposes.
Tip The link between the EMU and the personal account is per-user, not per-device. Once it is established, every new VM you provision will work after a single /login — there is no need to revisit aka.ms/copilot again unless you change your personal handle.
The bootstrap prompt
This is arguably the most valuable step in the entire setup. Before asking Copilot to build anything, instruct it to profile your machine and write itself a memory file. Paste the following verbatim:
I have Visual Studio 2026 Community Edition installed with C#,
.NET Framework 4.8.1 targeting pack, native C++ and C++/CLI.
Locate the installation paths using vswhere, verify that you can
create and compile a C# app, a native C++ app, and a C++/CLI app.
Then create a global copilot-instructions.md under
%USERPROFILE%\.copilot\ that documents the VS environment so
future sessions don't have to rediscover it.
The behavior that follows is informative to observe. Copilot uses vswhere.exe to locate the installation, reads setup.config.json, generates three disposable projects in your temp folder, builds them with MSBuild, parses the output, and on success writes a structured Markdown file to your user profile. That file is then automatically picked up by every future Copilot CLI session on this machine. The discovery work is performed exactly once.
What a good copilot-instructions.md looks like
Copilot CLI reads instructions from several well-known locations, in this order of precedence:
-
.github/copilot-instructions.md in the repo
- AGENTS.md (or CLAUDE.md, GEMINI.md) in the repo root
-
.github/instructions/**/*.instructions.md for path-scoped rules
-
%USERPROFILE%\.copilot\copilot-instructions.md as a global fallback
The machine-level file should be concise, declarative, and contain exact paths. A verified skeleton is shown below:
# Build environment on this PC (Visual Studio 2026)
- Visual Studio Community 2026, version **18.6.2**
- MSBuild **18.6.3**
- MSVC toolset **14.51.36231**, platform toolset name **v145**
- Windows 10/11 SDK: **10.0.26100**
- Default .NET Framework target: **net481**
## Key paths
| Purpose | Path |
|--------------------|------|
| VS install root | `C:\Program Files\Microsoft Visual Studio\18\Community` |
| vswhere.exe | `C:\Program Files (x86)\Microsoft Visual Studio\Installer\vswhere.exe` |
| MSBuild.exe | `...\18\Community\MSBuild\Current\Bin\MSBuild.exe` |
| MSVC cl.exe (x64) | `...\VC\Tools\MSVC\14.51.36231\bin\Hostx64\x64\cl.exe` |
| vcvars64.bat | `...\VC\Auxiliary\Build\vcvars64.bat` |
## Conventions
- For SDK-style csproj, always run `Restore` together with `Build`.
- New `.vcxproj` files must use `<PlatformToolset>v145</PlatformToolset>`.
- For C++/CLI: `<CLRSupport>true</CLRSupport>` and `<TargetFrameworkVersion>v4.8.1</TargetFrameworkVersion>`.
- Never put build output under `%TEMP%`.
Tip Treat copilot-instructions.md as a configuration file. Commit a repo-local version to your .github/ folder for projects with non-standard build flags (custom response files, signing scripts, and similar). The repo-local version overrides the global one.
Worked example: a C# console app on .NET Framework 4.8.1
Consider a task representative of customer-engineering work — a small utility that reads a registry key and emits JSON. Inside Copilot, enter:
Create a new C# console project targeting net481 in
.\RegistryProbe\. The app should accept a registry key path as
its single argument, read all values under it, and print them as
JSON to stdout. Add a few unit tests with MSTest. Build the
project with MSBuild in Release and show me the dotnet run output.
Behind the scenes Copilot will:
- Use vswhere to locate MSBuild (already cached via the instructions file).
-
Generate RegistryProbe.csproj with <TargetFramework>net481</TargetFramework>.
- Write Program.cs with appropriate argument parsing and a Microsoft.Win32.RegistryKey reader.
- Add an MSTest project, wire it up via a .sln file.
-
Run MSBuild /t:Restore,Build /p:Configuration=Release and read the output.
-
Run the binary against a safe key like HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion and present the JSON output.
For a more deliberate workflow, press Shift+Tab to toggle Plan mode. Copilot will produce an implementation plan first and wait for approval before writing to disk — a recommended practice for any work involving a customer reproduction.
Worked example: a native C++ command-line tool
The same approach applied to native C++. Prompt:
Create a new native C++ console project ".\PortPing\"
targeting x64, Release, using the v145 platform toolset and
Windows SDK 10.0.26100. The tool takes "host:port" on the
command line and prints "open" or "closed" depending on whether
a TCP connect succeeds within 1 second. Build it with MSBuild
and run it against microsoft.com:443.
The agent generates a PortPing.vcxproj that looks roughly like:
<PropertyGroup Label="Globals">
<PlatformToolset>v145</PlatformToolset>
<WindowsTargetPlatformVersion>10.0.26100.0</WindowsTargetPlatformVersion>
<ConfigurationType>Application</ConfigurationType>
</PropertyGroup>
…and builds it with:
& $msbuild "PortPing.vcxproj" /p:Configuration=Release /p:Platform=x64
Tip If you want Copilot to compile a single .cpp with cl.exe instead of going through MSBuild, instruct it to load vcvars64.bat first. This sets INCLUDE, LIB and PATH for the MSVC toolchain so that direct compiler invocations succeed.
Worked example: a C++/CLI interop assembly
C++/CLI is the workload that most commonly causes confusion in practice, because it requires the optional VC.CLI.Support component and a few non-obvious project properties. With Copilot, the task reduces to:
Create a C++/CLI class library ".\InteropBridge\" that targets
.NET Framework 4.8.1, uses the v145 toolset, and exposes a
managed wrapper around the native function CreateFileW. Add a
small C# console app in the same solution that consumes the
wrapper. Build everything Release|x64 and run the C# app to
prove the interop works.
The two critical lines that Copilot adds to the .vcxproj are:
<CLRSupport>true</CLRSupport>
<TargetFrameworkVersion>v4.8.1</TargetFrameworkVersion>
If the C++/CLI support component is not yet installed, Copilot will detect the corresponding "Cannot find <CLRSupport>" error, suggest the correct winget command to add the component, and offer to re-run the build.
Models, effort, and custom agents
Copilot CLI allows the model to be selected per session, and this selection should be made deliberately. The appropriate choice depends on the task at hand:
|
Profile
|
Recommended invocation
|
When to use
|
|
Fast iteration
|
copilot --yolo --model "claude-opus-4.8" --effort "medium"
|
Day-to-day work: scaffolding, small refactors, and build fixes.
|
|
Hard problems
|
copilot --yolo --model "claude-opus-4.7-1m-internal" --effort "high" --context "long_context"
|
Cross-file analysis, large reproductions, and complex C++ template errors.
|
|
Maximum autonomy
|
copilot --allow-all-urls --allow-all-tools --allow-all-paths --no-ask-user
|
Sandboxed Dev Box or VM only — never on a production laptop.
|
To determine which model best suits your purpose, consult the model comparison at https://docs.github.com/en/copilot/reference/ai-models/model-comparison. And if you have ever wondered what skills, tools, plugins and similar concepts actually are — or what an MCP server is for — the answers are available at https://docs.github.com/en/copilot/concepts/agents/copilot-cli/comparing-cli-features.
Useful slash commands within Copilot CLI
- /plan — produce an implementation plan before any code is written.
- /review — run the code-review subagent against the local diff.
- /diff — display the changes Copilot has made to the working tree.
- /agent — select a custom agent (explore, task, general-purpose, rubber-duck, code-review, research).
- /mcp — register an MCP server (useful for Azure CLI, Kusto, or internal tooling).
- /instructions — show which instruction files are currently loaded — useful when investigating unexpected agent behavior.
Tip Press Shift+Tab at any time to toggle Plan mode. For any action that would be recorded in a change ticket, planning first is inexpensive insurance.
Security & compliance for Microsoft FTEs
GitHub Copilot CLI falls within the scope of Microsoft's standard "responsible use of AI" guidance. Engineers at other enterprises should substitute the equivalent policy of their own employer, and individuals using a personal Copilot subscription should still treat these principles as a sensible default. The condensed guidance for engineers is:
- Do not paste customer data into prompts unless your engagement explicitly permits it. The agent will faithfully transmit such data to the model.
- Do not use --yolo on shared infrastructure. The flag pre-approves shell execution and file writes. Reserve it for personal workspaces or sandboxed Dev Boxes.
- Review the diff. Use /diff or git status before committing — Copilot will, on occasion, refactor files you did not anticipate.
- Secrets stay out of source. If you ask Copilot to test something that requires credentials, direct it to use azd, the Az module, or your Key Vault — never inline secrets.
- Telemetry and logs from the CLI reside under %USERPROFILE%\.copilot\logs. If a customer escalation requires evidence of agent actions, those logs serve as your audit trail.
Important Any action Copilot performs on your machine still runs as you. Treat agent sessions with the same care you would extend to a teammate with full access to your development machine.
Beyond Visual Studio: where else Copilot CLI helps
The Visual Studio scenarios in this article are the most obvious use case, but they are by no means the only one. The following list covers additional areas in which Copilot CLI has proven productive on real engagements.
- Generating and maintaining tests — Ask Copilot to write MSTest, NUnit or xUnit tests for an existing class, including mocks and boundary cases, or to fill coverage gaps in methods that were touched in the last commit.
- Refactoring across files — Rename a public API, extract an interface, or restructure a folder hierarchy and have Copilot propagate the change consistently throughout the solution, including project file references and unit tests.
- Modernizing legacy code — Port code from .NET Framework 4.8.1 to .NET 8/9, replace WebClient with HttpClient, or swap manual JSON parsing for System.Text.Json. Copilot handles the boilerplate; you review the deltas.
- Building customer reproductions from scratch — Translate a bug description from a support ticket into a minimal repro project. Copilot scaffolds the solution, simulates the failing call path, and runs it to confirm the symptom matches.
- Reviewing the local diff — The /review slash command analyses staged or unstaged changes and surfaces real issues — race conditions, off-by-one errors, missing input validation, dropped exceptions — while suppressing style-only noise.
- Writing and optimizing database code — Generate Entity Framework Core models and migrations from an existing schema, draft complex LINQ or raw SQL queries, and ask Copilot to inspect an execution plan and propose targeted indexes or query rewrites.
- Interpreting performance and memory profiles — Hand Copilot a PerfView trace summary, a dotnet-counters capture, or a BenchmarkDotNet result table. It identifies hot paths, allocation spikes, and contended locks, then suggests concrete code changes to address them.
- Generating documentation — Produce XML doc comments for public APIs, README sections, architecture overviews, or migration guides — written directly from the current code, not from a stale design document.
- Investigating unfamiliar codebases — Drop into a foreign repository and ask "what does this service do?", "where is authentication enforced?", or "which class handles cache invalidation?". The explore subagent answers with file and line references rather than vague summaries.
- Analyzing logs and traces — Point Copilot at an ETW trace, an Event Viewer export, a Fiddler capture, or a multi-megabyte server log. It groups errors, identifies the dominant failure pattern, and suggests next steps for the investigation.
- PowerShell, Bicep and other operational scripting — Beyond compiled applications, Copilot writes and debugs PowerShell modules, Bicep/ARM templates, Terraform configurations, and shell scripts — useful, among other things, for provisioning the very Dev Box or Azure VM described earlier in this article.
- Drafting technical communication — Generate the first draft of a customer-facing root-cause analysis, a pull request description, a release-note entry, or an internal incident retrospective directly from a diff or a chat transcript. The final wording remains yours; the boilerplate does not.
On a slightly meta note: GitHub Copilot CLI can also take a surprising amount of work off your hands when, for instance, you set out to write a blog post like this one. :-)
A note on customer data. Several of the scenarios above — building customer reproductions and analyzing customer-supplied logs in particular, but also any review, database or profiling task that involves production samples — may rely on material provided by a customer. Such data must always be handled with care: depending on the engagement, the customer's data-classification level, or the applicable regulatory regime, sharing it with a Copilot model may be restricted or outright prohibited. Public Sector engagements warrant particular caution. When in doubt, redact, reproduce against synthetic data, or confirm with your account team or compliance contact before pasting anything into a prompt.
Wrapping up
A clean Windows installation, two winget commands, one bootstrap prompt, and a global copilot-instructions.md are all that separate you from a fully working, AI-driven C# / C++ / C++/CLI workflow on Visual Studio 2026. From that point, the agent does what agents do best — it handles the routine work while you remain focused on the customer problem. The list of additional scenarios in the previous section is intentionally non-exhaustive — most engineering tasks that can be described in plain English are candidates, provided the agent has the relevant context and the required permissions.
Productive prompting — and may your builds remain evergreen.
Log in
