# 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](/mcp/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](https://github.com/Algiras/debugium/issues/48) · 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](https://github.com/Algiras/debugium/issues/15) · 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](https://github.com/Algiras/debugium/issues/35) · 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](https://github.com/Algiras/debugium/issues/33) · 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:

1. Overwrite the temporary breakpoint before the target is reached
2. Read stale breakpoint state during the restore phase
3. 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](https://github.com/Algiras/debugium/issues/32) · 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:

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

Currently, clients that cache the tool list after `init

[Read the thread](https://github.com/Algiras/debugium/issues/30) · 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](https://github.com/Algiras/debugium/issues/17) · 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](https://github.com/Algiras/debugium/issues/14) · 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):
  1.

[Read the thread](https://github.com/Algiras/debugium/issues/13) · 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](https://github.com/Algiras/debugium/issues/11) · 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](https://github.com/Algiras/debugium/issues/10) · 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](https://github.com/Algiras/debugium/issues/9) · 2026-03-03 · closed · 0 comments

The remaining reports are on [the project's issue tracker](https://github.com/Algiras/debugium/issues).