Repository navigation
Add condition, hitCondition, and logMessage to the Breakpoint type #596
Description
Problem
The SourceBreakpoint type (request side) includes condition, hitCondition, and logMessage, but the Breakpoint type (response/event side) does not. This means when a debug adapter sends a breakpoint event, the client cannot determine whether the breakpoint is a logpoint or conditional breakpoint.
Consequence: Logpoints sent via breakpoint events render as regular breakpoints in the UI — losing the logpoint icon and confusing users. Conditional breakpoints similarly lose their condition decoration.
Proposed Change
Add three optional fields to the Breakpoint type, mirroring SourceBreakpoint:
interface Breakpoint {
// ... existing fields ...
condition?: string;
hitCondition?: string;
logMessage?: string;
}
Rationale
Symmetry: line and column already round-trip between SourceBreakpoint and Breakpoint. condition, hitCondition, and logMessage should too.
Backward compatible: All fields are optional — existing adapters and clients are unaffected.
Enables correct rendering: Clients can use logMessage presence to render logpoints (◇) vs breakpoints (●), and display conditions in hover/detail views.
Unblocks AI usecase: In developing AI capabilities for debugging, logpoints and conditional breakpoints are particularly requested features as agents can easily leverage advanced breakpointing techniques.
Activity
connor4312 commentedon Feb 24, 2026
The client knows the kind of breakpoint a Breakpoint is, because it is the entity who sent it. The return value of
setBreakpointsis ordered based on the request, so as a client you know what Breakpointidmaps to whatSourceBreakpoint.aperez commentedon Feb 24, 2026
Connor Peet (@connor4312) This is not the case for
breakpointevents where the debugger needs to communicate to the client that breakpoints were installed. In such scenarios we would need theBreakpointtype to also be able to describe logpoints/conditionals.nsblake commentedon Feb 24, 2026
+1, there's a potential use-case here in that a debugger is already capable of programmatically setting breakpoints (i.e. outside of the client) and communicating these back to the client via
Breakpointevents. Without the support in theBreakpointtype, however, options for these breakpoints are relatively limited.connor4312 commentedon Feb 24, 2026
Are there cases where we have a DA actually doing that or wanting to do that?
kusmour commentedon Feb 24, 2026
We have a few use cases in LLDB (lldb-dap) for features that LLDB supports on breakpoints (most common being the condition, but it may not support with the format that VSCode offers; eg. only stop for a certain thread). Users will do such through lldb commands in the DEBUG CONSOLE repl. In reality, many debug adapters support capabilities outside of the DAP specification through commands or
customRequest. LLDB also recently started supporting MCP for agentic debugging. Programmatically setting/updating breakpoint/logpoint is of great value. It'd be great to treat these breakpoint types for the above reasons.efarka commentedon Feb 24, 2026
Connor Peet (@connor4312) we have built MCP tools where, for example, claude code can set breakpoints directly with a debugger. In this case vscode is not the sender of the breakpoints, and does not know about the breakpoints unless notified about them through breakpoint events. Using breakpoint events works great for this situation, and extending breakpoint events to include logMessage and condition will further enable our use case.
connor4312 commentedon Feb 25, 2026
But in that case the debug adapter would not be the one sending the breakpoints, right? VS Code already has client API that lets extensions set varying kinds of breakpoints.
aperez commentedon Feb 25, 2026
Please correct me if I'm wrong , but won't that API send a
setBreakpointsrequest to the adapter? Ideally we'd just want to update the VS Code UI to be consistent with the debugger's already-installed breakpoints.samisalreadytaken commentedon Feb 27, 2026
On the topic of
Breakpointextension, also see #30 and #8