Change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Read our guide about submitting issues: --<!-- Search existing issues to avoid creating duplicates. --<!-- Test using the latest Insiders build to see if your issue has already been fixed: --<!-- Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. --<!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes <!-- If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. --<!-- Issues caused by an extension need to be reported directly to the extension publisher. The 'Help Report Issue' dialog can assist with this. --- VS Code Version: 1.69.2 OS Version: Host: Mac OS 12.4 Remote host: Ubuntu 20.04.4 Steps to Reproduce: VS Code to a remote workspace over SSH with . the window. that there are now two fileWatcher processes. You can run to see that they are both running and consuming inotify watchers. VS Code. Observe that the fileWatchers are still present. Here's the proof of them still consuming watches via : They both have the same parent process: If you reload 5 times, you end up with 5 processes. In 1.68, the fileWatcher process closes when the window is reloaded or closed. This appears to be a new bug. This bug is causing Stripe engineers to consume all inotify watches on their development machines.
Updated to indicate that I tested w/ extensions disabled.
Validated that this does not happen when VS Code is open locally. Will update title/description to reflect that this is a remote development issue.
The processes do seem to go away eventually, but it takes many minutes. Due to the size of our monorepo, having just a few of these around can cause all inotify watches to be exhausted.
can you chime in, my understanding is that each client starts a management process and an extension host process which both should go away when the client disconnects (closes window, quits or reloads window). Did something change here? It is possible to configure excludes in settings (via ) to reduce impact on handles, did you try that?
Yup, I have already configured excludes to remove all third-party and codegenned artifacts in the repo. There's no more clear fat to trim there. VS Code watches far fewer files than Watchman or Bazel (which also run in the monorepo), but due to the size of our monorepo it is still a fair number of files. As an aside, I wish we could just have VS Code use watchman for notifications to reduce the file watching duplication here. EDIT: I know I say "just", but I understand that this would be a real feature undertaking -- not something that would take 5 minutes of time. I should be more careful with my wording!
Its funny you mention that because under the hood we do use and that has support for Watchman as a backend, we just never allowed to enable this because we have literally 0 testing on this backend since nobody is using Watchman here and could say if it actually works or not...
Oh, you are? For some reason, I thought I saw some commits by you that replaced this with some other watcher by default? Well, if there is a way to somehow experiment with using watchman as the backend, please let me know!
Bisect points to , with the most likely culprit being which fixes leaking extension host connections (and most likely introduces leaking management connections).
Thank you all for your quick response to this issue! I look forward to the next stable release with this fix. :)
can you also put this to the branch? Just checking in if the change will be different from the one that landed on .
Done! --
Steps to verify: use the extension to connect to open a folder (trust it if a prompt is shown) in an external terminal run check that a file watcher process is running go to the VS Code window and run in an external terminal run check that a new file watcher is running and the old one no longer shows up
I could reproduce the leaked watcher processes in VS Code 1.70 and I've verified that no watcher processes are leaked with the fix.

Discussion:
})); this._register(this._lifecycleService.onDidShutdown(() => { <ins> // We need to disconnect the management connection before killing the local extension host. // Otherwise, the local extension host might terminate the underlying tunnel before the // management connection has a chance to send its disconnection message. const connection = this._remoteAgentService.getConnection(); connection?.dispose(); </ins> this.stopExtensionHosts(); })); }