Python adapter validate() ignores executablePath, breaks virtualenv support

[elied]

Bug Description

The PythonAdapterFactory.validate() method calls findPythonExecutable() with no arguments, ignoring the executablePath provided when creating the debug session. This means the debugpy installation check always runs against the system Python rather than the user-specified interpreter.

This effectively breaks virtualenv support — if debugpy is installed in the venv but not in the system Python, the validation fails with "debugpy not installed" even though the target interpreter has it.

Steps to Reproduce

1. Have a Python virtualenv with debugpy installed
2. Have a system Python that does not have debugpy installed
3. Create a debug session specifying the venv interpreter:

   create_debug_session(language="python", executablePath="/path/to/venv/bin/python")
   

4. Set a breakpoint and start debugging
5. Get error: "debugpy not installed. Run: pip install debugpy"

Root Cause

In cli.mjs (around line 67634-67669), the validate() method does:

async validate() {
    // ...
    pythonPath = await findPythonExecutable();  // No arguments!
    // ...
    const hasDebugpy2 = await this.checkDebugpyInstalled(pythonPath);
    // ...
}

findPythonExecutable() accepts a preferredPath parameter and will use it when provided (line 66999-67005), but validate() never passes the session's executablePath.

Expected Behavior

validate() should pass the session's executablePath to findPythonExecutable() so the debugpy check runs against the correct interpreter.

Workaround

Install debugpy into the system Python (pip install debugpy). The actual debug launch does use the correct venv interpreter — only the pre-flight validation check is broken.

Environment

• OS: Ubuntu Linux (x86_64)
• Python: 3.9.18 (mise-managed, with virtualenv)
• mcp-debugger: installed via npx (@debugmcp/mcp-debugger)
• Client: Claude Code CLI

[debugmcpdev]

Fixed in 177116c — the validate() method now treats a missing debugpy as a warning rather than an error, so the Python adapter registers successfully even when debugpy is only installed in a virtualenv (not system-wide). The actual debug launch already uses the user's executablePath, so debugpy availability is verified at the right time.

What changed:

• PythonAdapterFactory.validate(): missing debugpy → warning (not error), with a message explaining the virtualenv scenario
• Added a dedicated test for the virtualenv case
• Improved session manager robustness for edge cases where a session terminates during startup

Thanks @elied for the excellent bug report — the root cause analysis and workaround were spot-on!