jedi-language-server: a Language Server Protocol front end for Jedi

What the server adds on top of Jedi itself

Jedi is a static analysis library for Python that most people meet through an editor plugin. jedi-language-server is the piece that puts it on the wire, speaking the Language Server Protocol so that any compliant editor can drive it.

The project description is narrow on purpose: a Python Language Server, with additional support for computational notebooks, powered by the latest version of Jedi. The stated principle is that if Jedi supports it well, this language server should too, which is a useful framing, because it means the feature set is a consequence of what Jedi can do rather than a separate design project.

What the server contributes is the protocol layer and the notebook handling. The Language Server Protocol is the standard that lets an editor ask questions about a document over a JSON-RPC channel, and a server that implements it correctly will give consistent completions, hover documentation, diagnostics and refactorings across editors, which is exactly what the older per-editor Jedi plugins could not offer.

The audience is split. There are people who want a Python language server and do not want a type checker in their editor, and there are editors whose Python support is thin enough that a dedicated server is welcome. The notebook support is what pulls in Jupyter users, since a .ipynb file is not something a plain Jedi plugin handles.

Maintenance mode, and the successor the project points at

The most important line in the readme is a banner at the top: MAINTENANCE MODE, with a suggestion that new users consider the successor to Jedi, a mypy compatible Python language server built in Rust, named Zuban and linked to its GitHub repository.

That is a handoff notice, and it changes how you should read everything else in the repository. A maintenance-mode project still works, and existing users will not find the server broken. But no new capabilities are being designed here, and the ecosystem is being pointed elsewhere.

The release history shows the same shape. Version 0.47.0 was published on 2026-05-31, 0.46.0 on 2025-10-25, and 0.45.1 on 2025-04-27. The last push to the repository was on 2026-06-23, and the repository is not archived.

The dependencies tell you why a successor is plausible at all. The package pins jedi at 0.19.2 or above and below 0.21, and pygls at 2.0.0 or above and below 3, plus cattrs, docstring-to-markdown and lsprotocol. A server that leans on pygls inherits pygls' own release pace, so a rewrite that does not depend on it can move faster. That is a reasonable reading, though the repository does not spell out a roadmap.

Installing it, and why pipx is the recommended route

Some frameworks, like coc-jedi and vscode-python, will install and manage jedi-language-server for you. If you are setting it up manually, the command is short:

pip install -U jedi-language-server

The documentation then recommends, alternatively and preferably, using pipx to keep jedi-language-server and its dependencies isolated from your other Python dependencies. The stated reason for the isolation is a bit unusual, worth repeating: don't worry, jedi is smart enough to figure out which virtual environment you are currently using.

That sentence resolves what is usually the messiest part of a Python language server. A language server has to import the project it is analysing so that it can resolve imports and read type information, which normally means it must run inside the project's environment. This one runs in its own isolated environment and then points Jedi at the environment you are working in.

The package manifest shows the entry point and the floor. The console script is jedi-language-server mapped to jedi_language_server.cli:cli, requires-python is 3.10 or above, and the classifiers cover Python 3.10 through 3.14. The development status is classified as Beta.

The initializationOptions block, and the defaults that surprise

Everything the server can be told to do arrives as a single JSON object of initializationOptions, and the readme documents each section separately. The full example is long, but the interesting part is what the defaults are.

Diagnostics are off by default. The configuration carries an enable flag set to false, alongside didOpen, didChange and didSave toggles that are all true. So the server is wired to react to document changes, and it is not reporting problems unless you turn them on. That is a deliberate difference from most language servers and it will look like a broken server to someone who expects errors in the editor.

Semantic tokens are also disabled by default, and the hover section is enabled, with a per-category disable map covering class, function, instance, keyword, module, param, path, property and statement.

Here is the shape of the object, trimmed to the parts that matter most:

    "diagnostics": {
      "enable": false,
      "didOpen": true,
      "didChange": true,
      "didSave": true
    },

The workspace section carries the environmentPath, which is where you point at the interpreter of the project you are analysing, along with a symbols object with an ignoreFolders list of .nox, .tox, .venv, __pycache__ and venv, and a maxSymbols value of 20.

autoImportModules trades goto definition for completions

The jediSettings section is where the trade-offs are explicit, and the autoImportModules option is the one that catches people out.

Modules that Jedi will directly import without analyzing. Improves autocompletion but loses goto definition. That is the whole documentation entry, and it is a real bargain rather than a bug. If you add numpy or pandas to autoImportModules, Jedi treats them as if they were already imported rather than resolving them through the project, so completion of numpy.xxx becomes instant. The cost is that navigating to the definition of a numpy symbol stops working, because there is no analyzed module to jump into.

The documented use case is performance. If you are noticing that modules like numpy and pandas are taking a super long time to load, and you value completions and signatures over goto definition, the recommendation is to list them:

{
  "jediSettings": {
    "autoImportModules": ["numpy", "pandas"]
  }
}

Two smaller options live alongside it. caseInsensitiveCompletion defaults to true, so completions match regardless of case, and can be set to false to make them case sensitive. debug defaults to false and prints Jedi debugging messages to stderr, which is the first thing to turn on when a completion behaves oddly and you cannot tell whether the problem is in the server or in your project.

Editor support across Neovim, Vim, Emacs and VS Code

Because the server speaks the standard protocol, the editor setup is mostly configuration, and the readme lists the options per editor.

For Neovim, the project is supported out of the box by Neovim's native LSP client through nvim-lspconfig, with a link to an example configuration. For Vim there are two actively maintained options, ALE and vim-lsp.

For Emacs, four choices are listed: lsp-jedi, eglot, lsp-bridge and lspce. The readme notes the list is non-exhaustive and invites a pull request for anything missing, which is a good sign for a project people actually use.

Visual Studio Code is the odd one out. Since the October 2021 release of the vscode-python extension, you set the python.languageServer setting to Jedi, and the extension manages the server itself. That is the path of least resistance for VS Code users, and it also means the server never appears in your own dependency list.

The general shape across all of these is the same: the editor spawns jedi-language-server, the server reads its initializationOptions, and the environmentPath tells it which interpreter to analyse against.

The development workflow, and what the repo layout shows

The repository is a Python package with the usual supporting scaffolding: a pyproject.toml built with hatchling, a Makefile, a noxfile.py for task automation, a .pre-commit-config.yaml, a uv.lock, an instance/ directory, a tests/ directory, a jedi_language_server/ package and an example-initialization-request.txt at the root.

That last file is a useful artefact for anyone integrating a client, since it is a sample of the actual initialize request with the full options payload, which is a better reference than reconstructing it from documentation.

The Makefile shows the maintainer's workflow in full. A setup target checks that uv is installed and prints the error and the install command if it is not, then runs uv sync --group dev, installs pre-commit and touches a .setup_complete marker file. There are separate fix, lint, typecheck and tests targets, each delegating to uv run nox -s, plus publish, which runs uv build and uv publish, and clean, which removes .venv and .setup_complete. The dev dependency group includes PyHamcrest, ty, nox, pre-commit, pytest, python-lsp-jsonrpc, ruff and slipcover.

The dependency on python-lsp-jsonrpc in the test group is the tell for how this is verified. The tests drive the server the way an editor does, over the protocol, rather than calling the internals, which is the right way to test a language server because the protocol surface is the product.

Editorial conclusion

Adopt jedi-language-server if you already have a Python environment where Jedi is installed and working, you want completion, hover and refactoring without adding a type checker, and you would rather not introduce a second, heavier analysis stack. Do not adopt it for a new project, because the project itself is in maintenance mode and recommends the successor, Zuban, a mypy compatible Python language server built in Rust, which is the direction the author points new users towards. Before you install, check that your editor can launch an LSP server over stdio, and read the initializationOptions block in the documentation, because several of the defaults, notably diagnostics being disabled and the symbol ignore list, will not match what you assume a language server does out of the box.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. pappasam/jedi-language-server on GitHub
4. README
5. Releases