microsoft / microsoft/AL

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

Open
#8,274 1 comment 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

accepted al-tools
Dominant language
PowerShell
Stars
881
Forks
285
Avg merge
3d 36m
Merged PRs (30d)
1

Description

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

Internal work item: AB#648588

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the facade al_publish and al_debug entry points and compare their accepted parameters with standalone almcp, then trace how launch.json selection reaches the AL launch path. Done means both facade tools can select a target or use a documented deterministic default without waiting for a VS Code picker.

Written by the indexing model from the issue text.

Assessment

Tech stack
vscode
Domain
developer-experience, tooling
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.