Anup Karanjkar

Posted on Nov 3 Originally published at wowhow.cloud

Claude Code in Visual Studio 2026: 5 Ways to Run It Today

#claudecode #visualstudio

As of November 2, 2026, Anthropic does not ship a Claude Code extension for Visual Studio 2026. The official docs cover VS Code, Cursor and JetBrains IDEs, and tell users of other editors to run the claude CLI in their editor's integrated terminal.[1][12] The GitHub feature request for a native Visual Studio 2026 extension, issue #15942, has been open since January 1, 2026 and had 480 thumbs-up reactions when we read it. None of the comments GitHub displays without expanding the thread comes from Anthropic staff.[2] That leaves five ways to run it today: the CLI in Visual Studio's terminal with a plain-text workflow, or one of four community extensions linked in that thread. Two of them, firish's and cv4vs Agents, connect the CLI to Visual Studio over the same IDE channel the official VS Code extension uses; dliedke's and nachum-shmilovitz-66's drive the CLI their own way.[3][11] This post compares all five, shows the setup commands, and shows which files the firish extension writes into your repo (and how to check the others), which most install guides skip.

How we researched this: the WOWHOW editorial team compared these extensions from their Visual Studio Marketplace listings, their READMEs and the Anthropic and Microsoft docs on November 2, 2026. We did not install them on a Visual Studio 2026 build, so every feature claim below is what the project documents, not what we measured.

TL;DR

No official Visual Studio 2026 extension exists. Anthropic's plugins cover VS Code, Cursor and other VS Code forks, and JetBrains IDEs; Visual Studio gets the CLI-in-a-terminal route.
Claude Code for Visual Studio (firish, v1.21.0, about 10,600 installs) is the closest thing to the VS Code experience: native diffs, Error List diagnostics, Roslyn lookups and a debugger Claude can read. VS 2026 only.
Claude Code Extension for Visual Studio (dliedke, v298.0, about 345,000 installs) is the most installed. It supports VS 2022 and 2026 and nine other agents besides Claude Code.
claude-code-visualstudio (nachum-shmilovitz-66) is the only one that reaches back to VS 2017.
cv4vs Agents (Corsinvest, v1.15.0, 415 installs) is the newest entrant: VS 2022 and 2026, native diffs, debugger tools, GPL-3.0 license.
All four are unofficial, need the Claude Code CLI plus a paid Claude plan or another supported provider, and two ride an undocumented protocol that a CLI update can break.

Why there is no official Visual Studio extension yet

Claude Code's IDE support is built around a small local protocol. The editor extension runs an MCP server named ide bound to 127.0.0.1 on a random port between 10000 and 65535, speaks unencrypted ws://, and writes a fresh auth token to a lock file at ~/.claude/ide/<port>.lock. The CLI reads that file and sends the token in an X-Claude-Code-Ide-Authorization header.[1] That is how diff viewing and diagnostic sharing reach the terminal agent.

Anthropic implements the editor side of that protocol for VS Code and for JetBrains IDEs, and the VS Code extension also installs in forks such as Cursor, Kiro and Devin Desktop. The JetBrains plugin runs the same ide MCP server with the same lock file and X-Claude-Code-Ide-Authorization header.[12] Visual Studio is a different product with a different extension model (VSIX on .NET, not a VS Code extension), so none of that code carries over. The docs never name Visual Studio. The phrase "Visual Studio Marketplace" appears only because that is where Anthropic publishes the VS Code extension.[1]

The demand is clear. The issue author writes that they rely on "Visual Studio 2026 for C++ and Win32 system-level development (e.g., global hooks, drivers)" and asks for a native VSIX "that provides feature parity with the existing VS Code extension": a chat panel, native diffs, context from open files, selections and build errors, and /ide support.[2] The issue carries the labels area:ide, enhancement and platform:windows. Most of the thread is developers linking their own workarounds. That is where the four extensions below came from.

The catch for anyone planning around this: an open issue with 480 reactions is not a roadmap. Pick a workaround on its merits, not on the hope that an official build lands next month.

Step zero: install the CLI on Windows

Every option here, including all four extensions, drives the real claude binary. None of them makes model calls itself. Install the CLI first. From PowerShell, using the native installer in Anthropic's setup docs:[7]

# PowerShell (prompt shows PS C:\). No admin rights needed.
irm https://claude.ai/install.ps1 | iex

# Open a NEW terminal, then confirm the install
claude --version
claude doctor

claude doctor prints read-only install and settings diagnostics without starting a session. If you prefer a package manager, winget install Anthropic.ClaudeCode works too. WinGet installs do not auto-update, though, so you need winget upgrade Anthropic.ClaudeCode on a schedule unless you set CLAUDE_CODE_PACKAGE_MANAGER_AUTO_UPDATE=1 in settings.json env, which makes Claude Code run the upgrade for you (it can fail while claude.exe is running). The native installer, by contrast, updates itself in the background.[7]

Two Windows details matter for Visual Studio users. First, Git for Windows is optional: with it, Claude Code uses Git Bash for its Bash tool; without it, it runs commands through PowerShell. If Claude Code cannot find Git Bash, point it there in settings.json:

{
  "env": {
    "CLAUDE_CODE_GIT_BASH_PATH": "C:\\Program Files\\Git\\bin\\bash.exe"
  }
}

Second, sandboxing is not supported on native Windows. Only WSL 2 supports it.[7] Most Visual Studio solutions (MSBuild, .NET Framework, Win32, drivers) need the native Windows toolchain, so you will usually run without the sandbox. That makes the permission prompts your main safety net, and it is the strongest argument for an extension that routes every edit through a diff you approve.

Last prerequisite: a paid plan. Claude Code needs a Pro, Max, Ultra, Team, Enterprise or Console account. The free claude.ai plan does not include it.[7] Paste the JSON above into the JSON formatter before saving if you are editing settings by hand. A stray backslash in a Windows path is the most common reason the file fails to load.

Option 1: the built-in terminal, no extension

This is the route Anthropic documents for editors without a plugin.[1] Open Visual Studio's terminal window (View > Terminal), cd to the folder that holds your .sln, and run claude. The agent reads and edits files on disk, runs dotnet build or msbuild, and Visual Studio picks up the changed files.

What you lose is everything the IDE protocol carries. No native diff for approving edits, no Error List feed, no selection context. You approve edits as text diffs in the terminal, and you paste build errors in by hand. For small, well-tested repos that is fine. In a large solution, where one wrong edit to a shared header triggers a long rebuild, the missing diff view hurts.

A short CLAUDE.md at the solution root closes part of the gap, because it tells the agent how to build and test without you repeating it each session:

# CLAUDE.md (solution root)
## Build
- Build: dotnet build MyApp.sln -c Debug
- Test:  dotnet test MyApp.sln --no-build
- Never edit files under obj/ or bin/.

## Conventions
- Target framework: net10.0. Do not retarget projects.
- Treat compiler warnings in src/Core as errors; fix them, do not suppress.

Swap in your own solution name and commands. If you keep a set of rules files you reuse across repos, the Production CLAUDE.md and AGENTS.md Rule Pack is a starting point.

firish, dliedke and nachum-shmilovitz-66 compared

Issue #15942 links four community extensions.[2] The table covers three of them: the two with the most Visual Studio Marketplace installs (dliedke and firish) and the only one that supports VS 2017 and 2019 (nachum-shmilovitz-66, which ships its VSIX files through GitHub Releases rather than the Marketplace). The fourth, cv4vs Agents, gets its own section after them. All four are free, unofficial, and not affiliated with Anthropic. The figures below come from each project's Marketplace listing or README on November 2, 2026.

	Claude Code for Visual Studio (firish)	Claude Code Extension for Visual Studio (dliedke)	claude-code-visualstudio (nachum-shmilovitz-66)

| How it talks to Claude Code | Implements the IDE protocol: WebSocket + lock file + MCP | Native chat tab (default) or embedded agent terminal | WebView2 chat; drives claude via stream-json over stdin/stdout |

| Edit review | Visual Studio's native diff, accept or reject | Tab showing uncommitted Git changes; opt-in per-file Keep/Undo of agent changes (no per-edit accept/reject listed) | Inline diff in chat plus an "Open diff" button for the native VS window |

| Debugger access | Reads call stacks, variables and threads; can step and set breakpoints with an opt-in toggle (managed .NET) | Sends unhandled exceptions with their stack trace while debugging (opt-in); F5, Ctrl+F5 and Shift+F5 forwarded from the embedded terminal. No variable or breakpoint access listed | Reads call stack, locals and exception when paused (verified on C#/.NET) |

| License | MIT | MIT per listing, plus a no-derivative-extensions clause | MIT |

Sources for the table: the firish README and listing,[3][4] the dliedke listing,[5] and the nachum-shmilovitz-66 README.[6]

firish: the closest to the VS Code experience

This one rebuilds the editor half of Anthropic's protocol inside Visual Studio. On launch it starts a localhost WebSocket server, writes the lock file to ~/.claude/ide/<port>.lock, and launches claude with ENABLE_IDE_INTEGRATION and the bridge port, so the CLI connects and speaks MCP over the socket.[3] Then it adds two more MCP servers: vs-debug for the debugger, tests and builds, and vs-semantic, a read-only server backed by the live Roslyn workspace for find-references, go-to-definition, call hierarchies and decompile.

For .NET work, the debugger access stands out. While you are paused at a breakpoint, Claude can read the call stack, locals and threads, and with an opt-in toggle it can step and set breakpoints itself. Test Explorer integration lets it re-run only failing tests.[3]

The README is honest about the limits. The protocol is "undocumented and version-fragile, so a claude update could change it." It was tested against claude 2.1.223, which is older than current CLI releases, so check the extension's release notes before updating the CLI. Debugger features target managed .NET code, so native C++ runtime inspection is not covered, even though C++ compiler diagnostics are. Diagnostics need a loaded project, and ARM64 Windows support is labeled experimental.[3] If you are the Win32 and drivers developer who opened issue #15942, that debugger gap is the one that matters.

dliedke: the most installed, and not only for Claude

With about 345,000 installs at version 298.0, this is the extension most Visual Studio users actually have.[5] New installs default to "Native mode", a chat in its own document tab. You can switch to an embedded terminal that runs the agent inside a Visual Studio tool window, which is also the fallback for agents that cannot run in native mode. Claude Code is the only agent shown in the picker by default. The others, Codex and Grok among them, are opt-in.

It does more Visual Studio-specific chores than the others: TFVC checkout, a git pull before the first prompt, opt-in sending of build errors, a commit-message generator, and a GitHub Issues window that fixes issues on separate branches. It also covers VS 2022, which firish does not. The trade-off is depth. Its debugger hooks are thin: while you debug, it can send unhandled exceptions with their stack trace to the agent (opt-in, under Settings > Automation), and since version 9.0 it forwards F5, Ctrl+F5 and Shift+F5 from the embedded terminal to Visual Studio's debug commands.[5] The listing does not mention reading locals, setting breakpoints or Roslyn lookups, so outside those exception reports Claude sees your code the way the CLI does, not the way Visual Studio does.

nachum-shmilovitz-66: for teams stuck on older Visual Studio

If your solution still builds only in Visual Studio 2017 or 2019, this is the only option of the four. It ships a separate VSIX per Visual Studio family and runs the claude CLI as a long-lived process, exchanging stream-json over stdin and stdout. Because it drives the real CLI, it inherits your login, CLAUDE.md, MCP servers and settings. It offers four permission modes (Ask before edits, Edit automatically, Plan mode and Auto mode), and in Ask before edits every tool call raises an allow or deny card.[6] With 9 stars it is also the least battle-tested. Read the source before you deploy it to a team.

cv4vs Agents (Corsinvest): the fourth extension in the thread

Its author posted it to issue #15942 on August 5, 2026 as "VS 2022 and 2026, GPL-3.0".[2] The Marketplace listing, published by Corsinvest Srl, shows version 1.15.0, 415 installs and a free price tag. That is far behind firish's 10,600 and dliedke's 345,000.[11] The listing says the real claude.exe runs in an embedded terminal "connected to the IDE over the same channel the official VS Code extension uses", and the author's issue comment lists /ide support.[11][2] The README says the extension "drives the real claude.exe" instead of forking the CLI, through a WebView2 chat pane and a ConPTY terminal pane. Visual Studio reaches the agent as 80 MCP tools covering navigation, references, rename, diagnostics, build, Test Explorer and the live debugger. Every edit shows as an inline diff and opens in Visual Studio's native side-by-side diff.[10]

On VS 2022 it fills the gap firish leaves. Its listing names breakpoints, tracepoints, stepping, locals and the call stack, which neither dliedke's listing nor the nachum-shmilovitz-66 README mentions for breakpoints or stepping.[11] The listing says its diagnostics keep working in C++, F# and TypeScript, but it does not say which runtimes the debugger supports. Two cautions. The license is GPL-3.0-only, not MIT, so check it against your company's tooling policy first. And the README does not say which files the extension writes into your workspace, so run the git status check below after the first launch.[10]

What these extensions write into your repo

Here is the part that bites teams later. The firish extension installs a PreToolUse hook into your workspace's .claude/settings.json to route edits to the Visual Studio diff, and registers its debugger shim in the workspace .mcp.json.[3] Both files usually live in version control, and the extension also writes PowerShell helper scripts (.ps1 files) into .claude/. Commit them unreviewed and every teammate's Claude Code session picks up a hook and an MCP server that points at an extension they may not have installed.

Check what changed right after the first launch:

# From the solution root, after launching the extension once
git status --short .claude/ .mcp.json
git diff -- .claude/settings.json .mcp.json

Then decide on purpose. Either commit the entries and make the extension a team requirement, or keep them out of your commits. Per the README, the extension writes its helper scripts (including the vs-mcp-shim.ps1 registered in .mcp.json) into your workspace's .claude/ folder and merges its hook into .claude/settings.json on every launch and connect. It overwrites the scripts unless you delete their vs:auto-managed marker line.[3] So the git status check above will list the .ps1 files too, and they come back after every launch. The diff checker helps when you are comparing a teammate's settings file against yours.

The README also flags a trust change. Since CLI 2.1.222, project hooks are tied to workspace trust, so after an update the hook can stop firing until you trust the folder again. The README's fix for a related issue is to remove duplicate project entries in ~/.claude.json that differ only by path casing.[3] Windows paths are case-insensitive, but that JSON file treats C:\Repos\App and c:\repos\app as two projects.

On the network side, the firish bridge binds to 127.0.0.1 only, checks the lock-file token on every connection, never logs the token, and makes no network or LLM calls of its own.[3] That matches the protection model in Anthropic's own docs, where the lock file sits at 0600 permissions inside a 0700 directory.[1] To see which bridges are live on your machine:

# PowerShell: list active IDE lock files (one per running bridge)
Get-ChildItem "$env:USERPROFILE\.claude\ide" -Filter *.lock

If the firish panel says "Waiting for CLI", its troubleshooting section says to click Launch Claude Code, or to run /ide in a claude terminal and pick Visual Studio.[3]

GitHub Copilot's Claude support is a different product

This causes a lot of confusion. VS Code can run Claude as a third-party agent harness inside Copilot Chat, controlled by the chat.agentHost.claudeAgent.enabled setting and billed either through a Copilot subscription or your own API key.[9] That page covers VS Code only. We found no Microsoft or GitHub documentation of the same Claude harness in Visual Studio 2026.

What Copilot in Visual Studio does share with Claude Code is the skills folder. GitHub's April 30, 2026 changelog says Visual Studio now discovers agent skills from .claude/skills/ and .agents/skills/ as well as .github/skills/.[8] So a skill you write for Claude Code in that folder also shows up for Copilot in Visual Studio. That is useful if half your team uses each tool. It is not the same as running Claude Code.

Which one to install

Your situation	Pick

| .NET on VS 2026, want native diffs and debugger context | firish, Claude Code for Visual Studio |

| VS 2022, want native diffs plus breakpoints and stepping, GPL-3.0 is acceptable | Corsinvest, cv4vs Agents (newest, 415 installs) |

| VS 2022, or a team that also uses Codex or another agent | dliedke, Claude Code Extension for Visual Studio |

| Solution pinned to VS 2017 or 2019 | nachum-shmilovitz-66, claude-code-visualstudio |

| Native C++ or drivers, where the nachum-shmilovitz-66 README verifies its debugger on C#/.NET only and says C/C++ is expected to work but not yet tested | Terminal route plus a strict CLAUDE.md; revisit when issue #15942 moves |

| Locked-down machine, no third-party VSIX allowed | Terminal route |

Whichever you choose, pin the CLI if your bridge is protocol-fragile. Setting "autoUpdatesChannel": "stable" in settings.json gives you a build that is about a week old and skips releases with major regressions,[7] which leaves the extension author time to catch up after a protocol change. Our October Claude Code changelog breakdown shows how often those releases land. For agent sessions that run unattended while you are in the debugger, set a hard budget first (see the Claude Code Spend Guard). If you are still choosing between agents rather than editors, start with our roundup of the best AI coding tools for 2026, and see the plugin marketplace guide for packaging the skills and hooks you build along the way. For a ready-made set of settings, hooks and rules, see the Claude Code Production Pack.

Install one extension, launch it once, and run git diff -- .claude/settings.json .mcp.json before your next commit. Whatever shows up there is now part of your team's setup.

Frequently asked questions

Is there an official Claude Code extension for Visual Studio 2026?

No. Anthropic ships plugins for VS Code (and forks such as Cursor) and for JetBrains IDEs, and points other editors to the CLI in an integrated terminal. Feature request #15942 for Visual Studio 2026 is still open.[1][2][12]

Does the VS Code Claude Code extension work in Visual Studio?

No. Visual Studio uses its own VSIX extension model, so VS Code extensions do not install in it. The Claude Code extension installs in VS Code and its forks only.[1]

Do I need a paid Claude plan to use these extensions?

Usually. All four extensions drive the Claude Code CLI, and the CLI needs a Pro, Max, Ultra, Team, Enterprise or Console account, or a third-party provider such as Amazon Bedrock, Google Cloud's Agent Platform or Microsoft Foundry.[7] cv4vs Agents also documents profiles for other Anthropic-compatible endpoints, with OpenRouter and Ollama among its examples.[10]

Does any extension support Visual Studio 2022?

Yes. The dliedke and cv4vs Agents extensions support 2022 and 2026, and the nachum-shmilovitz-66 project supports 2017 through 2026. The firish extension is 2026 only, with a 2022 build "planned if there is demand".[3][5][6][11]

Can Claude Code debug native C++ in Visual Studio?

None of these extensions documents tested native C++ debugger inspection. The firish debugger features are documented for managed .NET code. The nachum-shmilovitz-66 README verifies its debugger on C#/.NET only and says C/C++ is expected to work but not yet tested. The dliedke listing only promises to send unhandled exceptions with their stack trace, without naming a language. The cv4vs Agents listing names breakpoints, stepping and locals but not which runtimes they cover. Claude can still read C++ compiler errors through firish's Error List integration, and cv4vs Agents says its diagnostics work in C++.[3][5][6][11]

Will a Claude Code update break my extension?

It can. The firish README calls the IDE protocol "undocumented and version-fragile". Use the stable update channel and check the extension's release notes after a CLI update.[3][7]

Sources

12. JetBrains IDEs, Claude Code Docs, Anthropic (accessed November 2, 2026)

Originally published at wowhow.cloud

DEV Community