AL Debugger Cannot Open Files in Dev Container with Default /workspaces Mount

AL Debugger Cannot Open Files in Dev Container with Default /workspaces Mount

Environment

• VS Code Version: 1.95.1
• AL Language Extension Version: Latest (from devcontainer)
• OS: Linux (Arch, kernel 6.17.7)
• Dev Container: Yes, using official Microsoft .NET 8.0 runtime image
• Business Central Version: 26.4

Description

When debugging AL code in a VS Code dev container, the debugger successfully hits breakpoints and retrieves the call stack with correct file paths, but fails to open the source files in the editor. The error message is "The editor could not be opened because the file was not found."

Root Cause

The AL debugger sends file paths from inside the container (e.g., /workspaces/Denver-Wholesale-Florists/...) to VS Code running on the host machine. Since the host machine doesn't have a /workspaces directory, VS Code cannot resolve these paths to open the files, even though:

• The files exist at the exact path inside the container
• The files can be opened manually in VS Code
• The files can be accessed via terminal (cat, ls, etc.)

Steps to Reproduce

1. Create a dev container configuration for an AL project using the default VS Code workspace mount (which mounts to /workspaces/...)
2. Open the project in the dev container
3. Set a breakpoint in any AL file
4. Start debugging (F5) against an on-premises or sandbox BC environment
5. When the breakpoint is hit, observe that:
   • The debugger shows the correct call stack with file paths
   • Clicking on any stack frame shows "The editor could not be opened because the file was not found"

Expected Behavior

The AL debugger should open source files correctly when debugging in a dev container, regardless of the container mount path.

Current Workaround

Explicitly configure the dev container to mount the workspace at the same absolute path as on the host machine:

{
  "workspaceMount": "source=${localWorkspaceFolder},target=${localWorkspaceFolder},type=bind",
  "workspaceFolder": "${localWorkspaceFolder}"
}

This ensures the paths are identical in both the container and host, allowing VS Code to resolve them correctly.

Suggested Fix

The AL debugger should use VS Code's remote file system APIs to properly resolve file paths in remote/container scenarios, rather than sending raw file system paths that only work in non-remote contexts.

Additional Context

• This issue does NOT occur when developing outside of a container
• Other language extensions (e.g., Python, Node.js) handle this scenario correctly by using proper VS Code remote APIs
• The issue appears to be specific to how the AL extension communicates file locations during debugging

Internal work item: AB#613209

Start by reproducing the breakpoint navigation failure with the default /workspaces dev container mount, then trace how the AL debugger communicates source file locations to VS Code and review the referenced remote file system APIs. Done means clicking a call-stack frame opens the corresponding source file in the container without requiring a matching host path.