[FEATURE] LSP file-watch scope / exclusion for large and worktree-containing repos

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When the LSP tool starts a language server (for example jdtls for Java) in a large multi-module repository, the server roots at the project directory and recursively walks and watches the entire tree. On a big repo this saturates a CPU core and can lock up the machine during ordinary work, because a build rewrites thousands of generated files and the server is flooded with filesystem change events for files that are not source I am editing.

It gets worse when the repository contains nested Claude worktrees under .claude/worktrees/: each worktree is a full checkout, and all of them get swept into the same recursive watch, multiplying the watched file count several times over.

There is currently no way to tell the LSP integration to skip directories, so build output, generated sources, caches, and nested worktrees are all watched even though none of them are things I am editing. The result is that the LSP plugin becomes unusable on exactly the large codebases where code intelligence matters most.

Proposed Solution

Provide a way to exclude directories from LSP file watching, applied by the LSP client when it registers watchers (not just by the language server's own import settings). In rough order of preference:

1. A files.watcherExclude-style setting (a glob list) in .claude/settings.json that the LSP client honors, for example excluding /build/, /.gradle/, /.claude/worktrees/.
2. Respect .gitignore (and/or a dedicated .claudeignore) when setting up LSP watches, so generated and ignored trees are not watched by default.
3. Allow scoping the LSP workspace root to a subdirectory instead of the whole project.

The exclusion must apply to the OS-level watch. Language-server-level import filters (such as jdtls java.import.exclusions) do not prevent the client's recursive watching, so they do not solve this.

Alternative Solutions

• Tried java.import.exclusions in the language server config. It governs which projects the server imports, not the file watcher, so it did not stop the CPU storm.
• Tried disabling the plugin per-directory via settings scope. A repo-root disable leaks into nested worktrees, so the LSP cannot be gated to only the safe locations.
• Current workaround is disabling the language server plugin entirely and relying on a separate IDE for code intelligence, which defeats the purpose of the in-editor LSP tool.

Priority

High - Significant impact on productivity

Feature Category

Configuration and settings

Use Case Example

1. A developer opens Claude Code in a large multi-module Java/Gradle repository.
2. They run an LSP operation, which starts the language server rooted at the repo.
3. The server begins recursively watching the whole tree, including build output and any nested worktrees.
4. The developer runs a normal build in another terminal, which rewrites tens of thousands of compiled files.
5. The server is flooded with change events, a CPU core is pinned, and the machine becomes unresponsive.

With a watcher-exclude setting, the developer adds build, generated, and worktree globs to the exclusion list. The server ignores that churn, and code intelligence keeps working without the CPU storm.

Additional Context

The specific gap is that LSP file watching has no client-side exclusion mechanism. VS Code solves the analogous problem with files.watcherExclude and search.exclude.