VS Code file watcher and TypeScript language service: cache invalidation boundary during bulk file-system mutations

Integration boundary

VS Code's file watcher (Chokidar) and the TypeScript language service (tsserver) form an integration boundary where external bulk mutations — git checkout, reset, pull, or package-manager installs (npm ci, yarn install, pnpm install) — can leave tsserver's in-memory symbol indexes and module-resolution caches stale. The watcher may coalesce or drop events when large directory trees are replaced atomically, and VS Code does not automatically restart the TS server in response.

Constraints and uncertainty

No public event signals "external bulk change detected" for extensions to trigger automated recovery. The heuristic for deciding when a restart is warranted remains undocumented and varies by OS watcher backend (inotify, kqueue, FSEvents, polling). Remote development (WSL, SSH, Dev Containers) adds another watcher layer that can further delay or drop events. Behavior has been observed on VS Code 1.85–1.93; newer releases may introduce undocumented heuristic restarts.

Questions

1. What specific watcher-event patterns or thresholds should an extension monitor to reliably detect that a bulk mutation has likely invalidated tsserver caches?
2. Is there a supported programmatic signal — short of polling tsserver logs — that indicates the language service has fallen out of sync with the on-disk project graph?
3. For monorepo workspaces using project references, does the composite project graph cache require a full TS server restart, or can selective project reloads recover consistency?