al_compile/al_build MCP tools return stale cached success after a cross-project breaking change

1. Describe the bug

The Copilot/agent tool al_compile (and al_build) returns a stale, cached compilation result that does not reflect the current state of source files on disk.

In a multi-root workspace with two AL projects (an "App" project and a "Test" project that depends on it), after registering both projects and running an initial successful build/compile, the tools stop re-validating cross-project symbol references on subsequent calls:

• Renaming (or removing) a field in the App project that the Test project references does not surface as a compile error via al_compile/al_build, even after the App project itself is rebuilt and confirmed to compile cleanly with the new field name.
• al_getdiagnostics for the same project also returns the old, now-incorrect diagnostic locations/messages instead of current ones.
• A genuine command-line compile with alc.exe against the exact same files on disk correctly fails with AL0132 ("does not contain a definition for ...").
• The stale result persists across repeated calls, across re-running al_addproject for the project, and even when the same tool is invoked from a separate/fresh session ΓÇö it is tied to the running MCP server process, not to any particular caller.
• The only thing that resolved it was fully restarting the underlying MCP server process.

This makes al_compile/al_build unsafe to rely on for validating cross-project breaking changes ΓÇö they can report succeeded: true with zero diagnostics for code that genuinely does not compile.

Server setup: the al_compile/al_build tools are exposed by an MCP server registered in the user-level mcp.json (not project-local), launched via the al CLI ΓÇö installed as a .NET global tool ΓÇö with launchmcpserver --transport stdio:

"al-tool": {
    "type": "stdio",
    "command": "al",
    "args": ["launchmcpserver", "--transport", "stdio"]
}

This is a long-running stdio process shared across the whole VS Code session (and across subagent invocations) ΓÇö the staleness is tied to that one running process, not to any particular editor tab or caller.

2. To Reproduce

1. Create a two-project AL workspace: App (defines a table extension field) and Test (depends on App, references that field).

// App/Source/MyTableExt.al
tableextension 50100 "MyTableExt" extends "Job Task"
{
    fields
    {
        field(50100; "MyCustomField"; Boolean)
        {
            Caption = 'My Custom Field';
            DataClassification = CustomerContent;
        }
    }
}

// Test/Source/MyTest.Codeunit.al
codeunit 50100 "MyTest"
{
    Subtype = Test;

    [Test]
    procedure "Field is accessible"()
    var
        JobTask: Record "Job Task";
    begin
        JobTask."MyCustomField" := true;
    end;
}

2. Register both projects with the agent tooling (al_addproject for App, then for Test).
3. Run al_build (or al_compile) for Test ΓÇö confirm it succeeds.
4. Rename "MyCustomField" to "MyCustomField2" everywhere in the App project only (leave Test referencing the old name).
5. Run al_build for App directly ΓÇö confirm it succeeds (App is internally consistent).
6. Run al_compile (or al_build) for Test again, without restarting anything.
7. Compare against a genuine command-line compile of Test with alc.exe using the same .alpackages/source.

3. Expected behavior

Step 6 should fail with AL0132:

'Record "Job Task"' does not contain a definition for 'MyCustomField'

matching what the command-line alc.exe compile in step 7 reports.

4. Actual behavior

Step 6 reports:

{ "succeeded": true, "diagnostics": [], "message": "" }

(or, for al_build, "succeeded": true" with a package generated and no errors), while the equivalent alc.exe run fails with 2 real AL0132 errors at the exact expected locations. This was reproduced consistently across multiple repeated attempts, after re-adding the project via al_addproject, and from a separate subagent session ΓÇö the stale result only cleared after the MCP server process itself was restarted.

5. Versions:

• AL Language: 17.0.2273547 (compiler reported as 17.0.34)
• Visual Studio Code: 1.134.0
• Business Central: platform/application symbols observed at 28.4.53241.53873 (workspace app.json targets 27.0.0.0)
• List of Visual Studio Code extensions that you have installed: AL Language extension
• Operating System:
  • Windows
  • Linux
  • MacOS

Final Checklist

Please remember to do the following:

• Search the issue repository to ensure you are reporting a new issue

• Reproduce the issue after disabling all extensions except the AL Language extension

• Simplify your code around the issue to better isolate the problem

Internal work item: AB#648679

Reproduce the two-project scenario with al_addproject, al_compile, and al_build, then compare the results with alc.exe using the same files. Inspect the long-running launchmcpserver process and project-registration paths for cache lifetime and invalidation. Done means renaming the App field causes Test to report AL0132 without restarting the MCP server.