Summary
Currently, DebugMCP assumes a single active debug session model by binding operations to vscode.debug.activeDebugSession.
In complex application architectures (e.g. frontend + backend services launched via compound debug configurations, client/server setups, microservices, or parent/child worker processes), multiple DAP debug sessions run concurrently in the same VS Code workspace. When this happens, an AI agent cannot deterministically target or inspect a specific session without risking race conditions or relying on VS Code's global active session focus.
Motivation
For AI agents managing full-stack or multi-process debugging workflows:
- Targeted Inspection & Stepping: The agent needs to step or inspect variables in the backend service while the frontend service continues running (or vice-versa).
- Session Disambiguation: Without a session identifier, inspection tools (
get_variables_values, evaluate_expression) fail or hit the wrong target if another session steals focus.
Proposed Architecture & Prototype
We explored a working prototype of this approach on our fork here:
👉 Prototype Branch: https://github.com/ankitajha6475-jpg/DebugMCP/tree/feature/multi-session
👉 Key Implementation Commit: ankitajha6475-jpg@6943502
The core design in that prototype:
- Active Session Map in
DebuggingExecutor: Maintain a map of active debug sessions (Map<string, vscode.DebugSession>) updated via onDidStartDebugSession / onDidTerminateDebugSession.
- Optional
sessionId?: string Parameter: Add an optional sessionId to tool schemas:
step_over, step_into, step_out
continue_execution, pause_execution, restart_debugging
get_variables_values, evaluate_expression
- (And now potentially
get_debug_status)
- Graceful Fallback: If
sessionId is omitted, fall back to vscode.debug.activeDebugSession, keeping 100% backward compatibility for standard single-session workflows.
- Session Enumeration: Provide an easy way for agents to list active sessions (their IDs, names, and types) to discover target IDs.
Status & Contribution Handoff
We validated this pattern in our own workflows and wanted to document the architecture and share the reference branch for anyone in the community interested in taking this forward.
Because we currently lack the bandwidth to drive this implementation to completion or actively shepherd a PR, we are leaving this RFC and prototype open for the maintainers or any community contributor to adopt, adapt, or build upon whenever multi-session support becomes a priority.
Summary
Currently, DebugMCP assumes a single active debug session model by binding operations to
vscode.debug.activeDebugSession.In complex application architectures (e.g. frontend + backend services launched via compound debug configurations, client/server setups, microservices, or parent/child worker processes), multiple DAP debug sessions run concurrently in the same VS Code workspace. When this happens, an AI agent cannot deterministically target or inspect a specific session without risking race conditions or relying on VS Code's global active session focus.
Motivation
For AI agents managing full-stack or multi-process debugging workflows:
get_variables_values,evaluate_expression) fail or hit the wrong target if another session steals focus.Proposed Architecture & Prototype
We explored a working prototype of this approach on our fork here:
👉 Prototype Branch: https://github.com/ankitajha6475-jpg/DebugMCP/tree/feature/multi-session
👉 Key Implementation Commit: ankitajha6475-jpg@6943502
The core design in that prototype:
DebuggingExecutor: Maintain a map of active debug sessions (Map<string, vscode.DebugSession>) updated viaonDidStartDebugSession/onDidTerminateDebugSession.sessionId?: stringParameter: Add an optionalsessionIdto tool schemas:step_over,step_into,step_outcontinue_execution,pause_execution,restart_debuggingget_variables_values,evaluate_expressionget_debug_status)sessionIdis omitted, fall back tovscode.debug.activeDebugSession, keeping 100% backward compatibility for standard single-session workflows.Status & Contribution Handoff
We validated this pattern in our own workflows and wanted to document the architecture and share the reference branch for anyone in the community interested in taking this forward.
Because we currently lack the bandwidth to drive this implementation to completion or actively shepherd a PR, we are leaving this RFC and prototype open for the maintainers or any community contributor to adopt, adapt, or build upon whenever multi-session support becomes a priority.