Skip to content

Running start_debugging tool in VS Code Insiders does not return and agents keep waiting indefinitely. #39

Open

Description

This happens specifically when trying to debug a specific C# xUnit test using VS Code Insiders and GitHub Copilot.

How to reproduce:

  1. Ask the GitHub Copilot agent to place a breakpoint and start debugging a specific test in a C# xUnit project using VS Code Insiders.
  2. The agent successfully runs add_breakpoint tool.
  3. The agent makes a tool call to start_debugging using input like that:
{
  "fileFullPath": "/path/to/project/test.cs",
  "workingDirectory": "/path/to/project",
  "testName": "Test_Should_Do_Something"
}
  1. The agent keeps waiting indefinitely for the tool call to return any results.

Activity

  1. bendtherules commented on Apr 6, 2026

    @bendtherules

    +1 Doesn't work for js/ts also.

  2. teneko commented on Apr 26, 2026

    @teneko

    Very frustrating.. I have a C# project with a dedicated launchSettings.json and the only feedback I get is "No tests found in this file" once the LLM sets a breakpoint and starts the debugging. Anyway..

    TL;DR:
    DebugMCP falls back to coreclr for .cs files that effectively means: "debug current test file". That's why Program.cs or any other file in the project produces "No tests found in this file".

    Fix:
    Add an explicit .vscode/launch.json using type: "dotnet" and point it at the real app .csproj.


    Longer version:

    When DebugMCP cannot find a matching .vscode/launch.json config, it creates a default config from the current file.

    For .cs files, that default becomes coreclr.

    The problem is that DebugMCP handles coreclr like this:

    if (config.type === "coreclr") {
      // open current file
      // run testing.debugCurrentFile
    }

    So for an app entrypoint like Program.cs, it does not launch the app.
    It asks VS Code to debug the current file as a test file.

    That leads to:

    No tests found in this file

    The fix is to avoid the fallback completely and define the app launch explicitly:

    .vscode/launch.json:

    {
      "version": "0.2.0",
      "configurations": [
        {
          "name": "DebugMCP App",
          "type": "dotnet",
          "request": "launch",
          "projectPath": "${workspaceFolder}/src/<AppProject>/<AppProject>.csproj"
        }
      ]
    }

    The app’s runtime profile stays in:

    src/<AppProject>/Properties/launchSettings.json

    Example:

    {
      "profiles": {
        "DebugMCP": {
          "commandName": "Project",
          "launchBrowser": false,
          "applicationUrl": "http://localhost:<app-port>",
          "environmentVariables": {
            "ASPNETCORE_ENVIRONMENT": "Development"
          }
        }
      }
    }

    In the FAQ you say:

    DebugMCP automatically generates appropriate debug configurations based on the file's language/extension.

    I think "the appropriate debug configurations based on the file's language/extension" are in this case not correct. That should at least be documented, or the heuristic to determine the "appropiate debug configurations" improved.

  3. kouhe3 commented on Jul 10, 2026

    @kouhe3

    I want to use LLM debug my HTTP server. But start_debugging blocked the conversation until hit break point.

    I want my LLM using a debugger and shell at the same time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions