settings files.watcherExclude not working?

Reproduce the behavior on Windows with a RHEL 9 remote workspace and the supplied files.watcherExclude settings, then compare the result with native VS Code and GitHub Codespaces as reported. Trace how code-server passes these settings to the file watcher and verify whether targeted exclusions prevent the autofs and rclone endpoints from being mounted; done means excluded paths are not crawled or mounted.

Is there an existing issue for this?

• I have searched the existing issues

OS/Web Information

• Web Browser: latest Chrome
• Local OS: Windows
• Remote OS: RHEL 9
• Remote Architecture: x86_64
• code-server --version: 4.104.2 b0992ddb3e3b398371da6bcfbe21a70b4d66eb8d with Code 1.104.2

Steps to Reproduce

Our main project folder contains subfolders that make use of autofs + rclone. We do not want code-server attempting to traverse the MANY remote endpoints configured. The solution should be to use VS Code settings files.watcherExclude as implemented from https://github.com/microsoft/vscode/issues/150174

I have this setting in both the FOLDER (/files) and Workspace settings, but it appears to be ignored. Or is there another place to best handle this override?

{
    "files.watcherExclude": {
        "**/**": true,
        "**": true,
        "*": true
    }
}

That should effectively disable files watching completely. Optimally, I would like to use targeted filtering instead (which also does not have any effect) of globally excluding:

{
    "files.watcherExclude": {
        "/*files/cifs/**": true,
        "/*files/nfs/**": true,
        "/*files/s3/**": true,
        "/*files/sftp/**": true
    }
}

Expected

When I do df, I should not see any remote filesystems mounted.

Actual

As soon as I open the project workspace, it begins to crawl through all of the folders, which in turn, begins to mount every endpoint to do more crawling -- ugh!!

Logs

Screenshot/Video

No response

Does this bug reproduce in native VS Code?

Yes, this is also broken in native VS Code

Does this bug reproduce in GitHub Codespaces?

Yes, this is also broken in GitHub Codespaces

Are you accessing code-server over a secure context?

• I am using a secure context.

Notes

No response