[FEATURE] pyright-lsp plugin: support explicit project root / config path parameter to handle work in monorepos and across 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 using the pyright-lsp plugin in a Claude Code session whose working directory is not the root of the Python project being analyzed, Pyright runs without finding its pyrightconfig.json and therefore cannot resolve imports across packages — even stdlib.

The Pyright LSP server is initialized with the Claude Code session's primary cwd as the workspace root. It searches for pyrightconfig.json starting from that root. If the config lives in a different directory tree (e.g. a separate monorepo), it is never found.

Concrete scenario: I work across two repositories simultaneously — a design/documentation repo (primary cwd) and the-monorepo, a large Python monorepo. When I use the LSP tool on a file in the-monorepo, Pyright runs without a config, so cross-package imports are unresolved. Only in-file symbols (classes, methods defined in the same file) work. goToDefinition and hover on any imported symbol return "No definition found".

Running pyright --project the-monorepo/some_folder/python_root/ <file> from the CLI on the exact same file with the exact same pyrightconfig.json produces 0 errors and resolves all imports correctly. The config file exists and is correct — the problem is solely that the LSP tool cannot be told where to find it.

What works vs. what doesn't (same file, same config):

| Operation | Result |
|---|---|
| documentSymbol | ✅ Works (no import resolution needed) |
| hover on same-file class | ✅ Works |
| hover on imported symbol | ❌ "No hover information available" |
| goToDefinition on cross-package import | ❌ "No definition found" |
| pyright --project <dir> <file> via CLI | ✅ 0 errors, all imports resolved |

Proposed Solution

Add an optional projectRoot and/or configPath parameter to the LSP tool that maps to Pyright's --project CLI flag:

LSP(
  operation="hover",
  filePath="/path/to/file.py",
  line=42,
  character=10,
  projectRoot="/path/to/pyrightconfig-dir"   # ← new: dir containing pyrightconfig.json
  # or:
  configPath="/path/to/pyrightconfig.json"   # ← new: explicit config file path
)

When provided, the LSP server for that invocation should be initialized (or re-initialized) with the given root, equivalent to pyright-langserver --project <projectRoot>. This decouples the Pyright workspace root from the Claude Code session cwd.

Alternative Solutions

• Place a root-level pyrightconfig.json in the monorepo — partially works for one project's venv, but large monorepos have multiple projects with different Python versions and virtualenvs; a single root config cannot cover all of them correctly. When changing monorepo projects one have to regenerate the root-level pyrightconfig.json
• Open Claude Code from the target project root — works, but forces single-repo sessions. Unusable when the task spans a design/docs repo and a code repo simultaneously.
• Use pyright CLI via the Bash tool — works for diagnostics but loses all interactive LSP features (go-to-definition, hover, find-references) which are the primary value of the plugin.

Priority

Medium - Would be very helpful

Feature Category

MCP server integration

Use Case Example

1. I'm writing a tech spec in ~/projects/design-docs/ (Claude Code primary cwd)
2. I need to trace how a function works in ~/projects/the-monorepo/
3. I invoke LSP goToDefinition on the call site
4. Without this feature: "No definition found" — I fall back to manual grep across the monorepo
5. With projectRoot pointing at the-monorepo/some_folder/python_root/: Pyright resolves the import chain instantly, jumping through multiple internal packages

This is especially impactful in large monorepos with per-package-group pyrightconfig.json files (one config per project / venv), where there is no single root config that covers the whole repo.

Additional Context

Pyright's CLI supports --project <path> to specify the config root independently of the working directory. The LSP server (pyright-langserver) accepts the same via workspace rootUri in the LSP initialize handshake. The plugin could expose this as a per-call projectRoot and/or configPath parameter on the LSP tool.

Related issues:

• #15619 — LSP not auto-discovering installed servers (different problem: no server found vs. server found but wrong workspace root)
• #31391 — LSP not working in git worktrees (adjacent but VSCode-specific and different root cause)