DEV Community: Rishi Gulati

Claude Code in Visual Studio: now it drives the debugger, catches flaky tests, and reads library source

Rishi Gulati — Wed, 08 Jul 2026 18:41:05 +0000

Claude Code has this nice thing where it plugs into your editor. On VS Code or a JetBrains IDE, its edits open as a diff you accept or reject, it reads your compiler errors, and it knows what you have selected. On Visual Studio you get none of that. You copy and paste into a terminal like it is 2022. There is an open issue asking for Visual Studio support with a few hundred upvotes and no ETA, so I built the Visual Studio side myself.

It is a native VS 2026 extension. The important thing to say up front is what it is not: it is not another agent. The claude CLI does all the thinking. My extension is the IDE half of Claude Code's integration protocol, which I had to reverse-engineer off the wire since it is undocumented. It makes zero model calls of its own. It is a bridge.

The first thing you get is the diff gate. When Claude wants to change a file, the change opens in Visual Studio's own diff viewer, and approving there is the only step. No second yes/no prompt in the terminal. You can reject with a note, and it reconsiders.

That part was the plan. The part I did not expect is what became possible once the IDE half existed. Because I control the Visual Studio side, I could hand the agent things the CLI can never reach on its own. The one I keep coming back to is the debugger.

Watching the code run, instead of reading it

Here is a scoring function that returns the wrong total. Nothing in the source reads as wrong. The final number is just off. A fresh Claude session, with no idea what the bug was, was asked to check it, and it drove the Visual Studio debugger to find it in about ninety seconds.

It set a breakpoint at the top of the loop, started the session, and stepped through round by round, watching a combo counter. Here is the trace it kept, for the input {5, 3, 0, 4, 2, 0, 6}:

The bug is that the combo multiplier never resets on a zero round. if (points > 0) and else if (points < 0) both miss points == 0, so the streak carries across a zero and inflates the score. You cannot see that by reading the code. It only shows up when you watch the counter stay put across the round it should have cleared. That is the whole difference between reading code and debugging it, and the agent got to do the second one.

Reading runtime state is always on. Driving the debugger, actually stepping and setting breakpoints and running your code, is opt-in behind a toggle in the panel that resets every session, because it runs your program under the model's control.

It grew past stepping

Once the drive loop worked, the rest followed. Claude can now:

Attach to a process that is already running. A hosted web service or a desktop app, not just an F5 launch. It lists the processes, attaches, arms a first-chance exception, triggers the request itself with curl, and stops at the throw site inside the handler instead of the generic catch that swallowed it into a bland 500.
Untangle a deadlock. A deadlocked program never hits a breakpoint, so a breakpoint is useless. Claude pauses the hung process, reads each stuck thread's wait chain, and reconstructs the exact A -> B -> C -> A lock cycle, correctly ignoring the threads that are merely idle or busy.

And the one I am most proud of, because Visual Studio's own UI cannot even set it through an automation API: data breakpoints. Point Claude at a field and it stops the instant that field is written, or records every value the field takes, in order. It can watch conditionally (break only when the value goes below zero) and watch several fields at once.

I built a little fixture where an order's total is mutated through four different pricing methods and comes out negative, with no single line to breakpoint. Claude armed a plain watch, a conditional watch, and a second watch at once:

The conditional watch broke exactly on the write that corrupted the total, and the plain watch recorded the full timeline:

#	value (cents)	written by
1-3	0 → 30000 → 42000 → 54000	`AddItems`	three line items
4	54000 → 48600	`ApplyBulkDiscount`	10% off
5	48600 → 52488	`ApplyTax`	+8% tax
6	52488 → -47512	`ApplyLoyaltyCredit`	the corruption

Getting that to work was the hardest part of the whole project. There is no EnvDTE surface for it, so it rides a small Concord debug-engine component that ships with the extension and arms the breakpoint from inside the engine, then streams the changes back out over file IPC.

Catching a flaky test red-handed

dotnet test runs your tests. What it cannot do is stop inside a failing one in the debugger, or reproduce an intermittent failure on purpose and pause on it. So I wired Visual Studio's Test Explorer engine to the same debug session.

The signature move is catching a heisenbug. Point it at a flaky test and it loops the test under the debugger with break-on-thrown armed, lets the passing runs finish, and stops on the first failing run, paused at the throw with the exception live in the frame:

The honest twist in that run: when it read the frame, it found there were no captured locals at all, and the throw came straight out of an if (Random.Shared.Next(3) == 0) branch. The test was not exposing a product bug. The test itself was nondeterministic because it branched on an unseeded RNG. A re-run loop would have given you a different red line every time and never told you that. Being paused inside the exact failing run did.

Getting real per-test results out of the engine took a trick too. Its result callback is an internal interface you cannot implement in normal C#, so the extension emits a type that implements it at runtime with Reflection.Emit.

Reading code the way the compiler does

The last piece is less flashy but I use it constantly. Instead of grepping text for "where is this used," Claude asks Visual Studio's compiler (Roslyn) for the resolved answer: find-all-references, go-to-definition, find-implementations, and call and type hierarchies, resolved through interfaces, overrides, and overloads. It catches the cases text search gets wrong, like an explicit interface implementation or a virtual dispatch a grep can never tie back to the interface.

Tool	What it caught that a text search misses
find-implementations	`Triangle`'s explicit `IShape.Area`, which `.Area()` or `: IShape` never ties back to the interface
type-hierarchy	`Circle` and `Square` reach `IShape` transitively through `ShapeBase`; grep on `: IShape` finds only the two direct implementers
call-hierarchy	the interface-dispatched callers of `IShape.Area`, back to `Main`, that a search on the concrete `Circle.Area` would miss
go-to-definition	the right `Describe` overload at a call site, not all three declarations
decompile	the real body of `Enumerable.Sum` from the library, with `Math.Sqrt` falling back to SourceLink

It also does the one thing reading your repo fundamentally cannot: it decompiles the body of a method that lives in a referenced DLL. Point it at a framework or NuGet call and it hands back the real C#, the way Go-To-Definition does, and for core .NET types it fetches the actual runtime source over SourceLink.

How it hangs together

If you like the plumbing: the extension starts a localhost WebSocket server, writes a lockfile, and launches claude already connected. The diff, diagnostics, and selection tools ride Claude Code's IDE protocol directly. The debugger, the test runner, and the semantic tools ride two extra MCP servers the CLI reaches through a tiny stdio shim, because that channel is the open plugin door where the model actually sees the tools. Everything runs in-process against the live Visual Studio services, on the UI thread where it has to be. The CLI does all the agent work; the extension never calls a model.

The honest part

Visual Studio 2026 only for now. A 2022 backfill is possible if people want it.
The integration protocol is undocumented and could change on any CLI update, so I pin and smoke-test against a known-good version.
The debugger, test, and data-breakpoint features are .NET-focused.
It is free, MIT, and not affiliated with Anthropic. "Claude" and "Claude Code" are Anthropic's.

If you write C# and use Claude Code, I would genuinely like to know how it holds up on a real codebase.

Marketplace: Claude Code for Visual Studio
Source and docs: github.com/firish/claude_code_vs

The deep-dives (the full debugger tool list, the test loop, the semantic surface) are in the repo's docs/ folder if you want to see how far each piece goes.

I brought Claude Code to Visual Studio, then handed it the debugger

Rishi Gulati — Tue, 23 Jun 2026 19:00:23 +0000

Update: this extension has grown well past what this post covers. It now has a debugger Claude can drive, data breakpoints, test integration, and Roslyn code navigation. The current, fuller walkthrough is here: I brought Claude Code to Visual Studio, and gave it a debugger it can drive.

Plenty of times I've run a C# project in VS Code instead of Visual Studio, not because I like it better, but because that's where Claude could show me its edits in a real diff before I accept or reject. There's already an open request for something similar on GitHub with a stack of upvotes and no answer yet. So, I built the missing half myself.

It started as a diff window. I wanted Claude's edits to show up in the real Visual Studio diff instead of a yes/no prompt in a terminal. That worked, and so, I moved to the next biggest inconvenience, letting the Claude CLI read the compiler errors and warnings, the lint problems, and the rest of the build output directly, instead of copy-pasting them in. This was the v1 of my project.

The next biggest problem (and opportunity) came when I found myself using the debugger, and adding console logs and then hand-feeding those values to the Claude CLI to get it to debug a tricky issue with the correct context. So I started building a bridge between Visual Studio's debugger automation and the CLI. A few weeks later Claude was setting breakpoints in my files, stepping through them, watching variables mutate at different frames, and telling me where a bug was hiding that it would have probably skimmed past while reading my code.

Quick disclaimer first. This is an unofficial community project, not affiliated with Anthropic. It's open source, it targets Visual Studio 2026, and it needs the Claude Code CLI installed. The Anthropic CLI is the hero doing the actual model work. My extension is the IDE sidekick supporting it.

The run that made me excited

Check out this scoring function. Each round scores points, and a run of scoring rounds builds a combo multiplier. The first hit counts once, the second in a row counts double, and so on. A round that scores nothing should break the run and reset the combo.

It compiles. It runs. It prints the wrong number. Give it the rounds {5, 3, 0, 4, 2, 0, 6} and it returns 61, when the answer is 25. Nothing in the source looks wrong. No IDE warnings.

I opened a fresh Claude session that had never seen the file. Then I asked it to find what was tripping up.

It stepped through the rounds one at a time, reading the combo and the running total at each stop.

This is the trace it built as it went:

round	points	combo after	total	expected
0	5	1	5	5
1	3	2	11	11
2	0	2	11	11
3	4	3	23	15
4	2	4	31	19
5	0	4	31	19
6	6	5	61	25

Round 2 is the tell. The points are 0, so the combo should drop back to nothing. It stays at 2. Same at round 5. The run never resets, so every later round gets multiplied by a number that's too big and the total climbs to 61.

Then it pointed at the cause:

The zero case falls through both branches. The code handles points greater than zero and points less than zero, and a plain zero matches neither, so the combo never resets.

The bug is invisible in the output. The only way to catch it is to watch the combo fail to reset while the program runs, which is what a person does with a debugger (or a bunch of tracing statements), and what the agent did here. It didn't read the bug. It watched it. Start to finish, about a minute and a half.

Then it wrote the fix, and the fix opened where I would want it. Not as text in a terminal, but in Visual Studio's own diff viewer, with Accept and Reject right there.

The everyday part it rides on

That diff is the part I had been leaning on for weeks before any of the debugger work, and it's still what I use most. Every change Claude proposes opens as a real diff in the editor you already trust. You read it and click Accept or Reject. There's no second confirmation waiting back in the terminal.

The reject is the part I like. You don't just say no, you say why, in a sentence.

That note goes straight back to the CLI, and Claude picks it up and tries again with your correction instead of taking another blind swing.

It reads your build too. Errors and warnings from the Error List, C# and C++, reach the model directly, so it can see what's broken without you pasting anything in. And there's a docked panel that keeps the session honest: what you've accepted and rejected, tokens and cost, and a line for how much the agent has been inspecting the debugger versus driving it. The switch that lets it drive lives here as well, off until you turn it on.

Why this took real work

The obvious approach doesn't work, and that's most of the story.

Claude Code talks to an IDE over a small local protocol: a lockfile plus a localhost WebSocket speaking MCP. The catch is that the CLI is picky about which of the IDE's tools it actually shows the model. It hands over diagnostics and runs the rest itself. So I could register a new "read the debugger" tool and the model would never be allowed to touch it.

The debugger gets to Claude two other ways.

The first is a hook. Send a prompt while you're paused at a breakpoint and a hook fires, reads the break state out of Visual Studio, and drops it into the context before the model sees your message. No tool call. Claude starts the turn already knowing where you're stopped and what every local holds.

The second is a separate MCP server, the kind you register yourself for a project. Those aren't filtered, so any tool they expose, the model can call. The extension runs a small one for the debugger and registers it on launch. The work happens inside Visual Studio. A shim just shuttles messages to it.

Reading state was pretty easy. Driving the debugger was the part that kept getting errors. "Step over" isn't a question with an instant answer. You issue it, then you have to wait for the program to stop again before the result means anything. Block the UI thread to wait and you freeze the IDE. The solution is to implement the step such that it goes out without blocking the main UI thread, the extension listens for the debugger's mode-change event, holds the request, and finishes it when the next break lands. From the model's side it's one clean call that returns the new state. Underneath it's an event handshake that keeps the editor responsive.

Driving is also off by default. Reading runtime state is always on, since it can't break anything. Continue, step, breakpoints, starting and stopping a session: all of that sits behind the checkbox in the panel, and it resets every time you restart Visual Studio. Letting an agent run your code is a real decision, so its off by default.

What's next

A few things on the list:

Test driven debugging. Run the suite, and when a test fails, set a breakpoint at the failure, start debugging that test, and drive to the fault on its own.
(Work in progress) Break on thrown. Stop the instant a chosen exception is thrown, at the throw site, not wherever it gets swallowed.
CPU and memory. Point the .NET diagnostics tools at the running process and surface the hot methods and the heaviest allocations.

Try it

It's on the Visual Studio Marketplace, and the source is on GitHub. You need Visual Studio 2026 and the Claude Code CLI.

Marketplace: https://marketplace.visualstudio.com/items?itemName=firish.bridgev1
Source and docs: https://github.com/firish/claude_code_vs

If you work in Visual Studio and you've wanted Claude Code there, give it a try and tell me what breaks.