Qwen Code LSP: How to Enable It and Fix Missing Language Servers

Qwen Code 0.27.1 lets you enable experimental language-server support through user settings, without passing a startup flag. If definitions, references or diagnostics are missing, check three things separately: whether LSP is enabled, whether a server is configured, and whether the workspace is trusted.

The November 9 release includes the new opt-in. This matters especially for Desktop and Web Shell users whose client constructs the startup arguments. LSP itself was already present; the new setting makes it reachable without controlling that command line. It remains experimental and disabled by default.

Enable LSP at the user level

Merge the following into your user settings file, ~/.qwen/settings.json. Preserve the settings already there rather than replacing the file:

{
  "tools": {
    "lspEnabled": true
  }
}

Restart the client or session host after changing it. The value is read during startup, so editing the file while a session is running will not attach language servers to that session.

Putting the same setting in the repository's .qwen/settings.json will not work. The enablement design deliberately limits it to user, system and system-defaults scopes. A checked-out project should not decide that it can start more processes using your account's permissions.

For a CLI session, qwen --experimental-lsp remains another option. The operator environment can also enable it with QWEN_CODE_ENABLE_LSP=1; use the literal value 1, not true. Project environment files cannot supply this opt-in.

Configure one language server before adding more

Enabling the feature does not install a server. For a TypeScript project, install the language server and TypeScript:

npm install -g typescript-language-server typescript

Then put a .lsp.json file at the project root:

{
  "typescript": {
    "command": "typescript-language-server",
    "args": ["--stdio"],
    "extensionToLanguage": {
      ".ts": "typescript",
      ".tsx": "typescriptreact"
    }
  }
}

This example follows the versioned LSP guide. It is a configuration walkthrough, not a claim of hands-on testing. Start with one language so that a missing executable or incorrect file mapping does not get buried under several failing servers.

Workspace trust is a separate requirement. For a repository-declared server, enable security.folderTrust.enabled in user settings and explicitly trust a directory you have reviewed through the startup dialog or /trust, then restart. An IDE can also report workspace trust. Do not trust an unfamiliar checkout simply to remove an error: its language-server command runs with your permissions.

Read the status before changing the model

Run /status for a summary and /lsp for server details. An enabled service with no configured servers points to discovery or configuration; a configured server that fails to start points to its executable or initialization. Neither is a reason to switch models.

For a concrete verification task, save a TypeScript file containing a function and two call sites. Ask Qwen Code to locate the function's definition and references using LSP, without editing the file. Check that the returned locations correspond to those call sites. This is a proposed smoke test, not a benchmark or a guarantee that every subsequent refactor will be correct.

That distinction is useful in practice. A model can produce a plausible explanation from text search even when language-server support is broken. Asking for explicit symbol navigation makes it easier to see whether the new information source is actually available.

Why the setting can be on while LSP stays off

The tagged opt-in resolver checks QWEN_CODE_DISABLE_LSP=1 before the flag, enable variable or setting. If your operator environment contains that switch, adding more enable settings will not help. Conversely, setting tools.lspEnabled to false does not cancel an explicit enable flag or enable variable.

For an intentional shutdown, set the disable variable in the environment that launches the host, then restart it and verify the new session. A project .env is the wrong place to manage either switch.

There are also host-level refusals. Safe-mode sessions, bare mode, SSH workspaces and certain restricted hosts do not accept LSP. Do not assume a daemon startup flag proves the child session is protected. The merged change's review records a pre-existing forwarding gap where qwen serve --safe-mode did not carry safe mode into session hosts. For this version, verify the effective session state rather than relying on that daemon flag alone.

If the service is enabled but a server fails, check that its executable is installed and available to the process running Qwen Code. A desktop app's environment can differ from the terminal where you installed it. Use an absolute executable path when necessary, inspect the workspace trust decision, and check debug output from qwen --debug before changing unrelated settings.

What this changes for coding work

LSP can give an agent symbol-level evidence that a text match cannot provide. That is particularly useful when the same name appears in unrelated modules, but it does not replace compilation, tests or reviewing the resulting diff.

The useful upgrade here is a repeatable setup: one operator-level opt-in, an explicit workspace trust decision, and a server whose readiness you can inspect. Once those are working, a failed code change becomes something you can investigate instead of blaming an invisible configuration problem on the model.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams turn product changes and developer workflows into clear technical stories people can use and share.

Book a 30-minute call.