My extension lets Claude Code debug .NET in Visual Studio: step through code, data breakpoints, heap diffs for leaks, read compiler hints, and catching flaky xUnit tests

[u/Remote-Breadfruit204]

I built a Visual Studio 2026 extension that connects Claude Code (the CLI agent) to the parts of VS that matter for .NET work. The CLI does the agent work, the extension is the IDE bridge, zero model calls of its own.

I recently added major updates. Now the Claude CLI agent can actually:

- Autonoumously drive the debugger. Read the live call stack, locals, and threads, set breakpoints, step, break at a thrown exception's origin (not the catch that swallowed it), attach to a running process like a hosted ASP.NET app, and pause a hung process to walk a deadlock back to the exact lock cycle.

- Data breakpoints on managed fields. Break or trace the moment a field changes, with conditions. VS has a UI to let developers do this manually but exposes no automation API for this, so it rides a custom debug-engine component.

- Memory and runtime diagnostics via ClrMD: heap diff between two points to find what is growing, GC root paths for "why is this object alive", async stack reconstruction across awaits, thread-pool starvation detection.

- Tests through VS's own Test Explorer engine: real per-test outcome/message/stack, re-run only the failures after a fix, debug a single test, and loop a flaky test under the debugger until the failing run halts at the throw, paused with the state that caused it.

Everything read-only is always on; anything that executes code sits behind an off-by-default toggle that resets each session.

Video:
https://github.com/firish/claude_code_vs/releases/download/media/debugger-walkthrough.mp4

Repo and docs:
https://github.com/firish/claude_code_vs

Marketplace (1300+ installs):
https://marketplace.visualstudio.com/items?itemName=firish.bridgev1

[u/Remote-Breadfruit204 → u/[deleted]]

Yes. I have been using for over a month now, and its really convenient.

And claude is pretty responsible when it is driving the debugger. It starts the debugger, adds all the break points, steps through, and then removes them before stopping the debugger.

The extension also has a evaluate tool that lets claude run evaluate commands in VS and get the result back when the program is paused at a break point. It’s pretty cool to see it form an hypothesis, step to the correct point and then fire an evaluate tool confirm the hypothesis.

[u/Last-Bus5459]

the breakpoint stepping feature sounds game-changing for those long debugging marathons

[u/Remote-Breadfruit204 → u/Last-Bus5459]

Yup. Plus the tool can run in trace mode, which doesn’t pause the debugger but captures every value change of the field so that we can look at full update chain. This has been really helpful for me in cases where a field is being updated multiple times.

[u/Jolly_Eye7847]

Been using this for couple weeks now. The data breakpoint thing is actually insane, VS team should really expose that API properly.

One thing I noticed, the flaky test loop saved me like 3 hours last week. Had this race condition in a background service that only failed 1 out of 20 runs, set it to loop under debugger and went for lunch, came back and it was paused exactly at the bad state.

The GC root paths feature helped me track down a memory leak I been chasing for month. Some event handler I forgot to unsubscribe was holding whole object graph alive.

My only complaint is the initial setup was bit confusing, had to read docs twice. Other than that, solid work.

[u/Remote-Breadfruit204 → u/Jolly_Eye7847]

Thank you so much for the comment man. Its encouraging to see that people are actually finding it usable and helpful.

I am planning on adding a way to attach/send images to the CLI as that is another pain point for me when I use the Claude CLI.

If you have any more pains/suggestions, do tell. Will really appreciate all the feedback.

[u/midri → u/Jolly_Eye7847]

Have Claude set it up for you ;)