[BUG] LSP goToDefinition drops files in .venv

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

I am using the Claude Code (CC) LSP plugin with the Python ty language server. When Opus runs the language server's goToDefinition on symbols that have their definition in the virtual environment (.venv folder in my repo), Opus gets back "0 definitions" and cannot use the language server to navigate to the definition, although the language server correctly returns the definitions. The reason for this is that the CC harness filters out paths that are in the .gitignore file. Obviously, the virtual environment folder is always in the .gitignore file.

This means that the LSP plugin is only half useful. Its goToDefinition and other commands only work correctly on my own code, not on any libraries I am using.

What Should Happen?

Opus should be able to read code in the virtual environment (all third party packages I am using in my project) to understand it and craft code that uses the libraries in the virtual environment. In fact, when using the language server with my code editor manually, I use its goToDefinition to look at code in the virtual environment all the time.

Opus can use find, grep, etc. to get to the code definition, so there is no reason it shouldn't be able to do the same using the LSP plugin.

Error Messages/Logs

Steps to Reproduce

1. Setup simple python project with .venv folder in the repo root (default location) and install some libraries.
2. Create .gitignore file that includes .venv.
3. Setup Claude Code LSP plugin with e.g. ty language server or pyright language server.
4. Create a Python module that imports something from the virtual environment.
5. Tell Claude Code to check if goToDefinition with the LSP plugin works for symbols in the virtual environment.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.46

Claude Code Version

2.1.193

Platform

Anthropic API

Operating System

Other Linux

Terminal/Shell

Other

Additional Information

The behavior was apparently correct initially, until the following Github issue called it a bug: https://github.com/anthropics/claude-code/issues/26051

Apparently the Github issue led to a code change that now produces the wrong behavior described above.

Two other Github issues are also calling for the behavior that I expect (no filtering, or at least a way to opt out of filtering):

• https://github.com/anthropics/claude-code/issues/32373
• https://github.com/anthropics/claude-code/issues/61228

Those two have been closed without explanation.