CLion 2026.2 lets AI agents read the debugger through ACP

JetBrains shipped CLion 2026.2 in mid-July, and the feature I care about is not the C++26 reflection support, welcome as that is. It is a bundled skill that gives an AI agent direct access to the debugger: stack traces, breakpoints, variable values. The agent can stop at a breakpoint, inspect state and reason about the root cause without you copying output into a chat window. It works with GDB, LLDB and DAP debuggers, and the agent talks to it through ACP, the Agent Client Protocol. In Claude Code you invoke it as /clion-debugger, in Codex as $clion-debugger.

What shipped

• A bundled debugger skill exposed to agents over ACP, covering stack traces, breakpoints and variable values, aimed at autonomous root-cause analysis.
• Backend support for GDB, LLDB and DAP, so it covers native toolchains on macOS and Linux and anything that speaks the debug adapter protocol.
• An MCP server setup prompt when you start an AI session in the IDE terminal, so the plumbing is offered instead of hunted for.
• Debug profiles and C++26 reflection support in the same release.

The 2026.2 family has been rolling out since July 16. IntelliJ IDEA in the same wave bundles GitHub Copilot out of the box behind an agent picker and deprecates the Machine Learning Code Completion plugin, which tells you where JetBrains thinks the value moved: from local completion to agents that can act inside the IDE.

Why reading beats writing

Most coding-agent demos are about generation. The agent writes a function, a test, a migration. The failure mode everyone knows is the agent guessing at runtime behaviour from source alone, then confidently patching the wrong thing. With native C++ that guess is worse than usual: undefined behaviour, uninitialized memory, ABI mismatches and optimizer effects are invisible in the text. A debugger is the ground truth. Handing the agent the same view you would use yourself, a stopped frame and real values, removes an entire class of hallucinated diagnoses.

An agent that can only read source is debugging a model of your program; an agent at the breakpoint is debugging the program.

The ACP part matters as much as the debugger part. Because the integration is a protocol, not a JetBrains-only chat feature, the same skill is reachable from Claude Code and Codex today and from any future ACP client. I wrote about why that standard is the right layer in ACP, the agent standard; CLion 2026.2 is the first release where I would point someone at a concrete, daily-use payoff.

How I would use it in the first week

• Start with a reproducible crash, not a flaky one. Set the breakpoint yourself, then ask the agent to explain the state and propose a fix. Judge the explanation before the patch.
• Keep the agent on read-only debugger operations at first. Inspecting frames is cheap and safe; letting it step and continue through a long-running process is where sessions get slow and confusing.
• Log what the agent asked the debugger. The value is in seeing which variables it chose to inspect; that tells you whether it understood the failure or is fishing.
• Compare Claude Code and Codex on the same crash. The skill is identical, the agents are not, and the difference shows up in how many debugger round trips each needs.
• Pin your plugin and IDE versions. 2026.2 changes the agent picker and drops the ML completion plugin, so a mid-sprint upgrade can move things under you.

Where it does not scale yet

The obvious limit is that this only works for ACP-compatible agents. If your team's assistant of choice does not speak the protocol, you get nothing from the skill. The second limit is session cost: every debugger round trip is a tool call with a large context payload, and a deep native stack with big structs can burn a lot of tokens before the agent says anything useful. Long-running or multi-threaded processes make this worse, because the interesting state is transient and the agent's loop is not fast enough to catch it. And I have not seen JetBrains publish numbers on root-cause accuracy; the release notes describe capability, not a success rate. Treat it as a very good junior who can finally see the debugger, and measure before you let it drive.