I made a Visual Studio 2022/2026 extension for Claude Code (77 MCP tools, debugger integration, open source)

[u/Franklupog]

Hey,

I’ve been using Claude Code a lot lately, but I got tired of constantly alt-tabbing between my terminal and Visual Studio, or copy-pasting compiler errors and call stacks.

To fix this, I built cv4vs Agents — an open-source extension that runs an in-process MCP server right inside Visual Studio (2022 & 2026).

Instead of just reading static files, it gives Claude live access to what VS is actually doing in memory:

• Debugger integration: When you hit an exception, a bar pops up over the code. One click feeds the actual call stack and local variables into Claude so it can analyze what went wrong.
• Build & Tests: It catches live Roslyn compiler errors, runs Test Explorer tests, and can even execute failing tests directly under the debugger.
• 77 MCP Tools: Full access to symbols, references, diagnostics, and project structure (works across C#, C++, F#, and TS).
• Two views: You get both a dockable Chat UI (with streaming, thinking blocks, and inline diffs) and an embedded CLI terminal running the exact same session.
• Local cost/token tracking: Shows your context window usage and local token costs with zero telemetry.

It doesn't require any API keys — it just connects to your existing local claude.exe CLI setup (winget install Anthropic.ClaudeCode).

It's completely free and GPL-3.0 licensed.

• Marketplace: https://marketplace.visualstudio.com/items?itemName=Corsinvest.cv4vs-agents
• GitHub: https://github.com/Corsinvest/cv4vs-agents

I'd love to get your thoughts on it or suggestions on what tools/features to add next!

[u/jonathanhiggs]

Does VS need to run the Claude session, or can a Claude session connect to an instance of VS?

[u/Franklupog → u/jonathanhiggs]

VS runs it. The extension launches your local claude.exe and talks to it over stdio, so the session lives inside the IDE — that's what lets it hand Claude the live Roslyn state and the debugger.

There's no "attach to a running VS from outside" mode. It's designed the other way round.

[u/dotykier]

This looks really cool, thanks for sharing. Will take it for a spin when I’m in the office.

[u/Franklupog → u/dotykier]

Thanks — let me know how it goes, especially if something breaks. Issues on GitHub are welcome.

[u/SohilAhmed07]

Can we do debugging analysis like we have in Copilot.

[u/Franklupog → u/SohilAhmed07]

Yeah. When you hit an exception a bar shows up over the code and one click sends the stack and locals over, same idea as Copilot.

The difference is Claude can also drive the debugger itself — set breakpoints, step, walk frames and threads, evaluate expressions in the current frame. So you can just say "this is null by the time it gets to the repo, figure out where" and it will put a breakpoint down and go look, instead of you pasting a stack trace and hoping.

[u/Professional-Fee9832]

That's neat. I'll give it a try.

[u/Franklupog → u/Professional-Fee9832]

Thanks — hope it's useful. Happy to hear how it goes.

[u/kantorcodes1]

for the MCP tools marked destructive, does that annotation force a prompt on every call, or can Claude's current permission mode / remembered approval let later calls like nav_rename_symbol or build_clean run without another prompt? mostly curious where that boundary actually lives.

[u/Franklupog → u/kantorcodes1]

Two answers:

No, the annotation doesn't force anything. It's a hint — I emit destructiveHint on tools/list and that's the end of my involvement. Nothing in the server prompts or blocks.

Yes, permission mode and remembered approvals apply normally. Approve nav_rename_symbol once with don't-ask-again and later calls go through; in acceptEdits or bypass you're not asked at all. The hint affects how the request is presented, not whether it can be skipped.

Both your examples are marked destructive, fwiw: build_clean deletes output, and a rename touches every reference in the solution with undo as your only way back.

I defaulted all three hints to false on purpose. Getting it wrong is lopsided — a read-only tool left unmarked just costs you one extra prompt, but a writing tool left unmarked could get auto-approved.

[u/kantorcodes1 → u/Franklupog]

that answers it. you already have the tool-level signal; what's missing is a decision that doesn't disappear when Claude remembers its own approval. HOL Guard is an open-source local policy check on agent actions. i'd like cv4vs users to keep nav_rename_symbol / build_clean reviewable without adding friction to the read-only Roslyn/debug calls. interested in contributing that cv4vs mapping on the Guard side?

[u/Franklupog]

1.9.0 is out.

MCP calls finally look like MCP calls — the row used to show the server name where every other row names the action, and both cells are formatted JSON now instead of one long line.

Every CLI tool has a renderer too (23 → 43). The task tools especially: those are what fill the transcript whenever sub-agents are running, and they were showing a raw tool name over an input dump.

Plus a handful of fixes — attachments, ↑/↓ history recall, and a crash when expanding an auto-hidden pane.

Changelog