ALTool: telemetry options are treated as project paths in MCP/LSP startup

[LuisN27]

1. Describe the bug

The documented --disableTelemetry and --telemetryLevel off options are interpreted as project paths when starting the ALTool MCP/LSP servers. This prevents me from verifying that the intended telemetry opt-out was applied.

This was observed with AL Language 18.0.2819426 and ALTool 18.0.43.1464, the latest stable versions checked on 2026-10-06. The report concerns argument handling; it does not assert that telemetry was transmitted.

2. To Reproduce

1. Use the ALTool distributed with the AL Language extension above, and an existing local AL project with its symbol cache.
2. Start the server as a child process with redirected stdin/stdout (STDIO). Replace the placeholders below with local paths.
3. Inspect startup stderr. No Business Central connection, authentication, build, or test run is needed to observe the argument handling.

MCP, with the disable flag:

altool launchmcpserver "<AL-project>" --transport stdio --packagecachepath "<symbol-cache>" --outfolder "<temporary-output>" --nolog --disableTelemetry

MCP, with the telemetry level:

altool launchmcpserver "<AL-project>" --transport stdio --packagecachepath "<symbol-cache>" --outfolder "<temporary-output>" --nolog --telemetryLevel off

LSP, with the disable flag:

altool launchlspserver "<AL-project>" --packagecachepath "<symbol-cache>" --outfolder "<temporary-output>" --nolog --disableTelemetry

These invocations summarize observations from existing local projects. An independent minimal public project fixture has not been executed. No project-specific AL code is included because the unexpected project entries are the command-line options themselves.

Documentation:

• ALTool reference (MCP and LSP)
• AL Language extension changelog (agentic language server and telemetry options)
• AL Agent Tools overview

3. Expected behavior

Only the explicitly supplied AL project should be loaded. The documented telemetry options should be parsed as options and applied to the server. If an option is unsupported for a particular command, startup should clearly reject it rather than treat it as a project path.

4. Actual behavior

Sanitized startup messages:

MCP with --disableTelemetry:

Successfully loaded project: --disabletelemetry

MCP with --telemetryLevel off:

Successfully loaded project: --telemetrylevel
Successfully loaded project: off

LSP with --disableTelemetry (working-directory path replaced):

Warning: Folder not found: <working-directory>/--disabletelemetry

Possible diagnosis, not confirmed by Microsoft: static metadata/IL inspection suggests that Program.NormalizeOneToken lowercases option names, while these options are registered using camel-case names. This may account for the observed mismatch.

Additional static-only check: the official development-tools NuGet package 30.0.42.60748-beta appears to retain the same normalization/registration pattern in its net8.0 and net10.0 tool assemblies. It was not installed or executed, so this is not a claim of runtime reproduction on the beta.

5. Versions:

• AL Language: 18.0.2819426
• ALTool: 18.0.43.1464
• Visual Studio Code: Not involved; ALTool was launched directly as a standalone child process.
• Business Central: Not involved; this is local server startup with project/symbol files.
• List of Visual Studio Code extensions that you have installed: Not applicable to this standalone ALTool invocation; no VS Code extension host was used.
• Operating System:
  • Windows
  • Linux
  • MacOS

Final Checklist

• Search the issue repository to ensure you are reporting a new issue
• Reproduce the issue after disabling all extensions except the AL Language extension ΓÇö not applicable to the standalone process reproduction above; no VS Code host was used.
• Simplify your code around the issue to better isolate the problem ΓÇö reduced to server startup and the relevant command-line options; no project source is disclosed.

Internal work item: AB#653272