AL MCP (VS Code facade): al_publish / al_debug block on interactive launch-configuration picker — no non-interactive target, breaks autonomous agent loops

[FBakkensen]

1. Describe the bug

When driving the in-VS-Code AL MCP facade tools from an agent (GitHub Copilot Chat), al_publish cannot run unattended. When the active project has more than one configuration in launch.json, the tool triggers VS Code''s interactive "select configuration" QuickPick and then blocks waiting for a human click. An autonomous agent cannot answer a GUI picker, so the call stalls indefinitely.

The facade al_publish exposes no target parameters — there is no configuration / launchConfigName, no environmentName / environmentType / server / serverInstance / tenant / authentication. Target resolution is fully delegated to the AL extension''s launch path, which prompts. There is no way to specify the target in the tool call itself.

This differs from the standalone almcp process, whose al_publish does accept projectPath / environmentName / environmentType / tenant / schemaUpdateMode. The facade variant accepts none of these.

al_debug (zero parameters) is affected the same way — same launch-config dependency, same picker.

2. To Reproduce

1. Open a workspace whose active project has two or more entries in launch.json.
2. From Copilot Chat, invoke al_publish with debug=false.
3. A "select configuration" QuickPick appears in the VS Code UI.
4. The tool returns {"error":"No configuration selected"} (code: PUBLISH_FAILED) if the picker is dismissed, or hangs until a human selects an entry.

Tool input used:

{ "debug": false, "skipbuild": false, "type": "full" }

(No other parameters are accepted by the facade tool.)

3. Expected behavior

al_publish (and al_debug) should be drivable without UI interaction — e.g. one of:

• a configuration / launchConfigName parameter to select a launch.json entry by name, or
• explicit connection parameters (server, serverInstance, tenant, authentication, environmentName, environmentType) like the standalone almcp, or
• a documented deterministic default (e.g. the active Run/Debug selection or first config) with no interactive fallback when invoked via MCP.

4. Context

• al_build is unaffected — it takes a clean scope parameter and runs fully unattended.
• The blocker is purely the missing non-interactive target; it is independent of the publish destination (reproduces regardless of whether the target is reachable).

5. Versions

• AL Language: 18.0.x (pre-release)
• VS Code: 1.124.0
• OS: Windows

[ajkauffmann]

I can confirm this also applies when launch configurations are defined in a multi-root .code-workspace file, not only in a project-local .vscode/launch.json.

In our workspace we keep multiple AL publish environments in the workspace-level launch.configurations. When invoking the VS Code facade al_publish from Copilot, the same interactive configuration picker appears and blocks unattended execution because there is no way to pass the target launch configuration name to the tool.

As an interim workaround, I moved the full list of environments into a custom workspace setting and added a small PowerShell script that changes the active environment by rewriting the standard workspace launch.configurations section to contain only the selected AL launch configuration. That avoids the picker because the AL extension sees exactly one valid launch target. The PowerShell script is invokable using a skill to support agentic workflow as much as possible.

This works, but it is only a workaround. A first-class non-interactive parameter such as launchConfigName / configuration, or explicit environment connection parameters, would be much cleaner and would avoid having to mutate workspace configuration before publishing.