vrr/qwen-code
2
0
Fork 0
mirror of https://github.com/QwenLM/qwen-code.git synced 2026-05-05 15:31:27 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions 11

fix(lsp): 修复 LSP 文档、isPathSafe 限制，并提升 LSP 工具调用率 (#3615)

Browse source 
* fix(docs): correct outdated and inaccurate LSP documentation

- Remove reference to non-existent `packages/cli/LSP_DEBUGGING_GUIDE.md`
- Remove reference to unimplemented `/lsp status` slash command
- Replace incorrect `DEBUG=lsp*` env var with actual debug log location
  (`~/.qwen/debug/` session files with `[LSP]` tag)
- Remove external Claude Code documentation links (`code.claude.com`)
- Document `isPathSafe` constraint: absolute paths outside workspace
  are blocked, users must add server binary directory to PATH
- Add practical troubleshooting: `ps aux | grep <server>` to check
  if the server process is actually running
- Add clangd-specific guidance: `--background-index`, `compile_commands.json`
  location, and `--compile-commands-dir` usage
- Simplify trust documentation (remove vague "configure in settings")

* fix(lsp): allow absolute paths in LSP server command configuration

Previously, `isPathSafe` rejected any command containing a path
separator that resolved outside the workspace directory. This blocked
legitimate use cases where users specify absolute paths to language
server binaries (e.g. `/usr/bin/clangd`, `/opt/tools/jdtls/bin/jdtls`).

The fix allows:
- Bare command names resolved via PATH (unchanged)
- Absolute paths (explicit user intent, already gated by trust checks)
- Relative paths within the workspace (unchanged)

Only relative paths that traverse outside the workspace (e.g.
`../../malicious-binary`) are still blocked.

Closes: server silently fails to start when users configure absolute
paths in `.lsp.json`, with only a debug log warning visible.

* feat(lsp): inject LSP priority instruction into system prompt when enabled

The model was not using the LSP tool because the system prompt's
"Tool Usage" section never mentioned it. The tool description alone
("ALWAYS use LSP as the PRIMARY tool") was insufficient — models
follow system prompt instructions more reliably than tool descriptions.

Changes:
- getCoreSystemPrompt() accepts `options.lspEnabled` parameter
- When LSP is enabled, injects an instruction in the Tool Usage section
  telling the model to ALWAYS use the LSP tool FIRST for code
  intelligence queries (definitions, references, hover, symbols, etc.)
  instead of falling back to grep/readfile
- Updated client.ts to pass config.isLspEnabled() to the prompt builder
- Updated test mocks and snapshots

* feat(lsp): add symbolName parameter for position-free LSP queries

The model avoided calling LSP for findReferences, hover, etc. because
these operations required filePath + line + character which the user
rarely provides. The model would read files directly instead.

Changes:
- Add `symbolName` optional parameter to LspTool
- When symbolName is provided without line/character, auto-resolve
  the symbol's position via workspaceSymbol before executing the
  actual operation (findReferences, hover, goToImplementation, etc.)
- Update tool description with examples showing symbolName usage
- Move LSP priority instruction to top of system prompt for visibility
- Add debug logging for LSP prompt injection

This enables natural queries like:
  {operation: "findReferences", symbolName: "Calculator"}
  {operation: "hover", symbolName: "addShape"}
without requiring the user to know exact file positions.

* feat(lsp): add LSP reminder to grep/readfile tool descriptions

When LSP is enabled, the model often chose grep or readfile instead
of LSP for code intelligence queries. Now the competing tools'
descriptions include a note reminding the model to use the LSP tool
for definitions, references, symbols, hover, diagnostics, etc.

This "push-pull" approach:
- System prompt pushes toward LSP (top-level priority instruction)
- Grep/ReadFile descriptions pull away from code intelligence usage

* fix(docs): align LSP doc with isPathSafe change — absolute paths now supported

The doc still said "absolute paths outside the workspace are not
supported" but the code was changed to allow them. Updated all
three places (Required Fields table, Troubleshooting, Debugging)
to reflect that absolute paths are now accepted.

* fix(lsp): improve symbol-based tool resolution

* fix(lsp): normalize display paths across platforms

* fix(lsp): narrow docs and path safety changes

* fix(lsp): add edge-case tests for isPathSafe and fix Chinese comment

- Add test for intermediate path traversal (./a/../../../etc/passwd)
- Add test for forward-slash relative paths (tools/clangd)
- Replace Chinese JSDoc with English on requestUserConsent

* fix(lsp): rename requestUserConsent to checkWorkspaceTrust

The method only checks workspace trust level and does not actually
prompt the user for consent. Rename the method and update the JSDoc
and call-site log message to accurately reflect the behavior.
This commit is contained in:
易良 2026-04-30 15:24:18 +08:00 • committed by GitHub
parent f771acb353
commit 49e462c021
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
3 changed files with 154 additions and 45 deletions
Download patch file Download diff file Expand all files Collapse all files

64
docs/users/features/lsp.md
View file

@ -40,7 +40,7 @@ You need to have the language server for your programming language installed:
### .lsp.json File
You can configure language servers using a `.lsp.json` file in your project root. This uses the language-keyed format described in the [Claude Code plugin LSP configuration reference](https://code.claude.com/docs/en/plugins-reference#lsp-servers).
You can configure language servers using a `.lsp.json` file in your project root. Each top-level key is a language identifier, and its value is the server configuration object.
**Basic format:**
@ -104,9 +104,9 @@ Example:
#### Required Fields
| Option | Type | Description |
| --------- | ------ | ------------------------------------------------- |
| `command` | string | Command to start the LSP server (must be in PATH) |
| Option | Type | Description |
| --------- | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------- |
| `command` | string | Command to start the LSP server. Supports bare command names resolved via `PATH` (e.g. `clangd`) and absolute paths (e.g. `/opt/llvm/bin/clangd`) |
#### Optional Fields
@ -148,6 +148,8 @@ For servers that use TCP or Unix socket transport:
Qwen Code exposes LSP functionality through the unified `lsp` tool. Here are the available operations:
Location-based operations (`goToDefinition`, `findReferences`, `hover`, `goToImplementation`, and `prepareCallHierarchy`) require an exact `filePath` + `line` + `character` position. If you do not know the exact position, use `workspaceSymbol` or `documentSymbol` first to locate the symbol.
### Code Navigation
#### Go to Definition
@ -315,7 +317,7 @@ LSP servers are only started in trusted workspaces by default. This is because l
- **Trusted Workspace**: LSP servers start if configured
- **Untrusted Workspace**: LSP servers won't start unless `trustRequired: false` is set in the server configuration
To mark a workspace as trusted, use the `/trust` command or configure trusted folders in settings.
To mark a workspace as trusted, use the `/trust` command.
### Per-Server Trust Override
@ -338,11 +340,12 @@ You can override trust requirements for specific servers in their configuration:
### Server Not Starting
1. **Check if the server is installed**: Run the command manually to verify
2. **Check the PATH**: Ensure the server binary is in your system PATH
3. **Check workspace trust**: The workspace must be trusted for LSP
4. **Check logs**: Look for error messages in the console output
5. **Verify --experimental-lsp flag**: Make sure you're using the flag when starting Qwen Code
1. **Verify `--experimental-lsp` flag**: Make sure you're using the flag when starting Qwen Code
2. **Check if the server is installed**: Run the command manually (e.g. `clangd --version`) to verify
3. **Check the command**: The server binary must be in your system `PATH`, or specified as an absolute path (e.g. `/opt/llvm/bin/clangd`). Relative paths that escape the workspace are blocked
4. **Check workspace trust**: The workspace must be trusted for LSP (use `/trust`)
5. **Check logs**: Look for `[LSP]` entries in the debug log (see Debugging section below)
6. **Check the process**: Run `ps aux | grep <server-name>` to verify the server process is running
### Slow Performance
@ -351,41 +354,34 @@ You can override trust requirements for specific servers in their configuration:
### No Results
1. **Server not ready**: The server may still be indexing
1. **Server not ready**: The server may still be indexing. For C/C++ projects with clangd, ensure `--background-index` is in the args and a `compile_commands.json` (or `compile_flags.txt`) exists in the project root or a parent directory. Use `--compile-commands-dir=<path>` if it is in a build subdirectory
2. **File not saved**: Save your file for the server to pick up changes
3. **Wrong language**: Check if the correct server is running for your language
4. **Check the process**: Run `ps aux | grep <server-name>` to verify the server is actually running
### Debugging
Enable debug logging to see LSP communication:
LSP debug logs are automatically written to session log files in `~/.qwen/debug/`. To check LSP-related entries:
```bash
DEBUG=lsp* qwen --experimental-lsp
# View the latest session log
grep '\[LSP\]' ~/.qwen/debug/latest
# Common error messages to look for:
# "command path is unsafe" → relative path escapes workspace, use absolute path or add to PATH
# "command not found" → server binary not installed or not in PATH
# "requires trusted workspace" → run /trust first
```
Or check the LSP debugging guide at `packages/cli/LSP_DEBUGGING_GUIDE.md`.
You can also verify the server process is running:
## Claude Code Compatibility
Qwen Code supports Claude Code-style `.lsp.json` configuration files in the language-keyed format defined in the [Claude Code plugins reference](https://code.claude.com/docs/en/plugins-reference#lsp-servers). If you're migrating from Claude Code, use the language-as-key layout in your configuration.
### Configuration Format
The recommended format follows Claude Code's specification:
```json
{
"go": {
"command": "gopls",
"args": ["serve"],
"extensionToLanguage": {
".go": "go"
}
}
}
```bash
ps aux | grep clangd # or typescript-language-server, jdtls, etc.
```
Claude Code LSP plugins can also supply `lspServers` in `plugin.json` (or a referenced `.lsp.json`). Qwen Code loads those configs when the extension is enabled, and they must use the same language-keyed format.
## Extension LSP Configuration
Extensions can provide LSP server configurations through the `lspServers` field in their `plugin.json`. This can be either an inline object or a path to a `.lsp.json` file. Qwen Code loads these configs when the extension is enabled. The format is the same language-keyed layout used in project `.lsp.json` files.
## Best Practices
@ -406,7 +402,7 @@ qwen --experimental-lsp
### Q: How do I know which language servers are running?
Use the `/lsp status` command to see all configured and running language servers.
Check the debug log for `[LSP]` entries (`grep '\[LSP\]' ~/.qwen/debug/latest`), or verify the process directly with `ps aux | grep <server-name>`.
### Q: Can I use multiple language servers for the same file type?