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

[StefanMaron]

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

[StefanMaron]

Additional Note on Workaround Limitation:

The workaround of mounting the workspace at the host's absolute path will not work for GitHub Codespaces accessed through the browser, since:

1. The browser-based VS Code has no concept of the "host" file system
2. Codespaces always use the mount path by default
3. There's no way to create symlinks or modify the host file system in a browser environment

This means the AL debugger is currently incompatible with browser-based Codespaces debugging. The only viable solution for Codespaces users is for the AL extension to properly use VS Code's remote file system APIs.