Add condition, hitCondition, and logMessage to the Breakpoint type

[efarka]

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.

[connor4312]

The client knows the kind of breakpoint a Breakpoint is, because it is the entity who sent it. The return value of setBreakpoints is ordered based on the request, so as a client you know what Breakpoint id maps to what SourceBreakpoint.

[aperez]

The client knows the kind of breakpoint a Breakpoint is, because it is the entity who sent it.

@connor4312 This is not the case for breakpoint events where the debugger needs to communicate to the client that breakpoints were installed. In such scenarios we would need the Breakpoint type to also be able to describe logpoints/conditionals.

[nsblake]

+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 Breakpoint events. Without the support in the Breakpoint type, however, options for these breakpoints are relatively limited.

[connor4312]

Are there cases where we have a DA actually doing that or wanting to do that?

[kusmour]

Are there cases where we have a DA actually doing that or wanting to do that?

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]

@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]

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]

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.

Please correct me if I'm wrong , but won't that API send a setBreakpoints request to the adapter? Ideally we'd just want to update the VS Code UI to be consistent with the debugger's already-installed breakpoints.