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

#dotnet #csharp #ai #visualstudio

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.