Reported issues for debugium

Pod holds 16 of 17 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.

Back to debugium.

Most discussed

Add integration tests for Node.js (js-debug) child session routing

Problem

The child session routing (PR #40) is a major feature enabling Node.js/TypeScript debugging, but has no dedicated integration tests. All 75 existing tests use Python (debugpy).

Scope

Test that js-debug child session connects and breakpoints hit
Test that get_debug_context returns correct data through child client
Test step_over/evaluate work through child session
Test timeline and console output capture from child

Prerequisites

Requires js-debug adapter to be available

Read the thread · 2026-03-03 · closed · 1 comment

Session persistence: export/import debug sessions

Summary

Allow exporting a debug session's accumulated knowledge (breakpoints, annotations, findings, timeline, watches) and importing it into a new session on the same codebase.

Motivation

Debugging knowledge currently dies with the session. If the program crashes and needs re-launch, all annotations and findings are lost. Session persistence lets debugging knowledge survive across sessions and be shared between team members or AI runs.

Implementation Plan

MCP Tools

`export_ses

Read the thread · 2026-03-03 · closed · 1 comment

Split mcp/mod.rs into focused modules

Summary

Refactor crates/debugium-server/src/mcp/mod.rs (2,166 lines) into smaller, focused modules.

Motivation

The MCP module is the largest file in the codebase. Adding new tools requires navigating a monolith. Splitting improves discoverability, reduces merge conflicts, and makes the codebase more approachable for contributors.

Proposed Structure

crates/debugium-server/src/mcp/
├── mod.rs              # Re-exports, McpContext, top-level serve()
├── protocol.rs         # RpcRe

[Read the thread](https://github.com/Algiras/debugium/issues/12) · 2026-03-03 · closed · 1 comment

### feat: Add goto/gotoTargets DAP support

## Description
Add MCP tools for the DAP `goto` and `gotoTargets` requests, allowing execution to jump to a specific line without running intermediate code.

## DAP Requests
- **gotoTargets** — query valid jump targets for a given source location. Requires `supportsGotoTargetsRequest`.
- **goto** — move execution to a target returned by `gotoTargets`. Requires a valid `targetId`.

## Use case
"Skip ahead to line N" or "re-run from line N" without restarting the session. Complements `continue_unt

[Read the thread](https://github.com/Algiras/debugium/issues/54) · 2026-03-03 · closed · 0 comments

### feat: Add cancel DAP request support

## Description
Add an MCP tool for the DAP `cancel` request, allowing in-flight requests (like long-running `evaluate` or `continue`) to be cancelled.

## DAP Request
- **cancel** — cancel a pending request by its sequence ID. Requires `supportsCancelRequest`.

## Use case
When an `evaluate` expression hangs or a `continue` runs too long, the AI agent can cancel the request rather than waiting for timeout.

## Implementation plan
1. Track outgoing request sequence IDs in the DAP client
2. Add `c

[Read the thread](https://github.com/Algiras/debugium/issues/53) · 2026-03-03 · closed · 0 comments

### step_until tool description should clarify condition is a runtime expression

## Problem

The `step_until` tool description says "condition expression" but doesn't clarify that this is evaluated as a **runtime expression in the debuggee's scope** (e.g., Python expression, JS expression), not a debugger metadata condition like "line > 45".

A user (or LLM) might try `step_until(condition="line > 45")` expecting to step until reaching line 45, but this evaluates `line > 45` as Python code, which fails silently (no variable named `line`), causing it to always hit max_steps.

[Read the thread](https://github.com/Algiras/debugium/issues/36) · 2026-03-03 · closed · 0 comments

### explain_exception returns misleading data when not stopped on an exception

## Problem

When `explain_exception` is called while paused at a normal step/breakpoint (not an exception), it still returns what appears to be exception context:

```json
{
  "exception": {
    "breakMode": "unhandled",
    "description": "exception: no description",
    "details": {
      "typeName": "exception: type unknown"
    }
  }
}

This happens because debugpy's exceptionInfo request returns metadata about the current stack frame even when no exception is active, and the tool does

Read the thread · 2026-03-03 · closed · 0 comments

Gate set_logpoint on supportsLogPoints capability

Problem

The `set_logpoint` tool is always shown in `tools/list`, but DAP adapters declare log point support via the `supportsLogPoints` capability. If an adapter does not support log points, the tool will silently set a normal breakpoint instead (the `logMessage` field is ignored).

Proposed Solution

Add `("set_logpoint", "supportsLogPoints")` to `CAPABILITY_GATED_TOOLS` in `mod.rs`. Most modern adapters (debugpy, node, lldb-dap) do support log points, so this is more about

Read the thread · 2026-03-03 · closed · 0 comments

Most recent

continue_until can race with concurrent MCP tool calls

Problem

The `continue_until` tool temporarily modifies breakpoints (saves → adds temp → continues → restores). If another MCP tool call (e.g. `set_breakpoint`) arrives concurrently, it can:

Overwrite the temporary breakpoint before the target is reached
Read stale breakpoint state during the restore phase
Leave the breakpoint state inconsistent

Impact

Low in practice (MCP clients typically wait for tool responses), but the implementation is not safe under concurrent tool d

Read the thread · 2026-03-03 · closed · 0 comments

Send tools/listChanged notification when sessions start or stop

Problem

The MCP spec (2025-11-25) defines a notifications/tools/listChanged notification that servers should send when the available tool list changes. Since we now filter tools/list by adapter capabilities, the tool list changes when:

A new session is launched (tools become filtered)
A session is stopped (tools revert to the full unfiltered list)
A session with a different adapter type is started (different capabilities)

Currently, clients that cache the tool list after `init

Read the thread · 2026-03-03 · closed · 0 comments

Memory inspection and disassembly for native debugging (C/C++/Rust)

Summary

Add memory read/write and disassembly tools for native debugging via DAP readMemory, writeMemory, and disassemble requests.

Motivation

For C, C++, and Rust debugging, memory corruption bugs often require inspecting raw memory. Disassembly helps understand optimized code behavior. These are niche but critical for native debugging scenarios.

Implementation Plan

MCP Tools

read_memory(memory_reference, offset?, count) — returns hex dump + ASCII
`write_memory(memor

Read the thread · 2026-03-03 · closed · 0 comments

Hit count breakpoints (hitCondition)

Summary

Add hit count breakpoints — break on the Nth hit of a breakpoint. DAP SourceBreakpoint supports hitCondition (e.g., "== 100", ">= 5").

Motivation

Essential for debugging loops — "break on the 100th iteration" without manually stepping. Combined with conditional breakpoints, this covers the full breakpoint expressiveness that DAP offers.

Implementation Plan

Server

Extend BpSpec with hit_condition: Option<String>
Include hitCondition field when building `S

Read the thread · 2026-03-03 · closed · 0 comments

explain_exception compound tool

Summary

Add an explain_exception compound MCP tool that auto-gathers all relevant context when stopped on an exception.

Motivation

When the AI hits an exception, it currently needs 4-5 separate calls: get_exception_info, get_debug_context, get_stack_trace, evaluate, get_console_output. A single compound tool provides a structured diagnosis in one round-trip.

Implementation Plan

MCP

New tool: explain_exception(session_id?)
Implementation (one call does all):

Read the thread · 2026-03-03 · closed · 0 comments

continue_until (run to cursor) via temporary breakpoints

Summary

Add a continue_until(file, line) compound tool that resumes execution until a specific line is hit, using a temporary breakpoint.

Motivation

"Run to cursor" is one of the most common debugging actions. Currently the AI must manually: set a breakpoint → continue → remove the breakpoint. A single compound tool eliminates this boilerplate.

Implementation Plan

MCP

New tool: continue_until(file, line, timeout_secs?)
Implementation:
1. Save current breakpoints for the

Read the thread · 2026-03-03 · closed · 0 comments

Smarter get_debug_context: auto-expand, watches, and timeline delta

Summary

Enhance get_debug_context to return richer data in a single call, reducing the number of follow-up MCP round-trips the AI needs.

Motivation

In nearly every debugging session, get_debug_context is followed by get_variables calls to expand nested objects. This adds latency and token cost. A smarter single call would make the AI workflow tighter.

Proposed Enhancements

1. Auto-expand nested variables (depth 1-2)

If a local variable has variablesReference > 0, automa

Read the thread · 2026-03-03 · closed · 0 comments

Log points (non-stopping breakpoints with logMessage)

Summary

Add log points — breakpoints that evaluate a template string and print it to the console without stopping execution. DAP SourceBreakpoint already supports logMessage.

Motivation

Log points let the AI instrument code non-intrusively — like adding print statements without modifying source. Useful for tracing values through a hot loop without the overhead of stopping at every iteration.

Implementation Plan

Server

Extend BpSpec with log_message: Option<String>
Inc

Read the thread · 2026-03-03 · closed · 0 comments

The remaining reports are on the project's issue tracker.