CLion is moving debug configuration out of the UI and into a JSON file an agent can rewrite

Debug profiles arrived in CLion 2026.2 as a way to configure and switch debuggers ^[15]. The next release adds a JSON form of the same thing, editable by hand or with an agent's help, exposing more configuration options than CLion's UI currently does ^[16]. The second half of that is the load-bearing part. The UI stops being the ceiling on what a profile can say, and the profile becomes a file you can check in, diff and review. It also gives an agent something to type into, which a modal dialog never did.

The import path is the cheaper half of the same feature. A team can bring an existing JSON debug configuration across from VS Code and get the same debugger settings without reconfiguring from scratch ^[17]. Whether that saves you anything depends on whether the fields you actually use in a launch config have equivalents in the profile schema, and nobody can check that until the schema ships.

The HardFault skill is aimed at a real gap rather than a demo. HardFault_Handler usually catches the fault and tells you nothing about what faulted ^[6]. The answer sits in the CPU state at the moment of the crash: registers, the stack frame, the fault status registers, sometimes disassembly ^[7]. That read is precisely what embedded teams script for themselves. JetBrains plans to hand the same reads to an agent, which gets memory, register and disassembly views on top of the stepping and breakpoints already exposed since the MCP debugging feature shipped ^[10][8].

For that to transfer to your bench, three things have to hold. Your target is an ARM Cortex-M part, since that is the fault the roadmap describes ^[5]. The crash is reachable with real hardware attached, which is the workflow the skill is built for ^[11]. And your agent is one the IDE can detect, offer and launch in the terminal, which is how the setup-assist flow is specified ^[12].

Order matters more than the feature list suggests. The skill is planned for a future minor release, and the minors are the 2026.2.x line ^[9][1]. The JSON profile is for the next release, 2026.3 ^[16][1]. Minors land before the next stable, so the agent gets the crash-state tools some months before it gets the config file it could write ^[1]. Handing a whole embedded setup to an agent in one pass is two hops, not one.

JetBrains labels the roadmap preliminary and says it cannot guarantee every listed item will be implemented in CLion 2026.2 ^[4]. The hedge names 2026.2 only, while the stated window also covers 2026.3 ^[2]. I read that as a hedge on the near half of the list and silence on the far half, which is where TRACE32 and QNX sit in the highlights ^[3].

If I ran an embedded team, the in-house artifact I would stop extending is the fault triage script. The peripheral viewer is the other candidate, since the DAP work names a peripheral view alongside RTOS thread and FreeRTOS object debugging ^[14]. What I would keep is anything that runs in CI with no IDE open, because none of this is specified to work there. LLDB 21 on Windows and a GDB update on all platforms are in the same window, and they are plumbing rather than strategy ^[18].