Support multiple debug sessions within the same workspace

Inizia individuando le implementazioni TypeScript di stop_debugging e restart_debugging, quindi esamina il routing del workspace aggiunto da PR #104 e la gestione di configurationName in launch.json. Confronta le opzioni sessionId e list_debug_sessions descritte qui; il lavoro è completato quando le sessioni in un workspace possono essere identificate e arrestate o riavviate senza ambiguità.

Problem

DebugMCP supports selecting a launch.json configuration when starting a debug session via configurationName.

However, when multiple debug sessions are running within the same VS Code workspace, stop_debugging and restart_debugging provide no way to specify which session they should operate on.

For example, a launch.json may contain two configurations:

• Admin site
• Customer site

Both configurations use the exact same:

• program
• cwd

but have different environment variables, such as APPLICATION_DOMAIN and HTTP_PORT.

Therefore, once both sessions are running, there is no unambiguous way for stop_debugging or restart_debugging to target one of them.

Relation to #25 / #104

This does not appear to be a duplicate of #25.

PR #104 added support for concurrent debug sessions across different VS Code windows/workspaces by routing requests to the appropriate workspace.

This issue is about a different level of concurrency: multiple debug sessions within the same workspace.

Workspace-level routing therefore isn't sufficient to distinguish the sessions.

Possible solution

One option would be to expose a debug session identifier and allow operations such as:

stop_debugging(sessionId)
restart_debugging(sessionId)

However, the MCP client should not necessarily be expected to already know the session ID. A debug session may have been started manually in VS Code, or by another client/session.

A list_debug_sessions operation could therefore expose the currently active debug sessions, including their identifiers and useful information such as the configuration name, program, and state. The client could then identify the appropriate session and use its sessionId when calling stop_debugging or restart_debugging.

For example:

list_debug_sessions()
        ↓
[
  { id: "abc", configurationName: "Admin site", ... },
  { id: "def", configurationName: "Customer site", ... }
]
        ↓
restart_debugging("def")

Alternatively, allowing stop_debugging / restart_debugging to directly target a configurationName could address the common launch.json use case, although a session ID would be more robust when multiple instances of the same configuration are running.

Thanks!