Repository navigation
Jedi LSP error: Unsupported position encoding (PositionEncodingKind.Utf16) in VSCodium #25710
Description
I read the “Reporting a bug” wiki page and I’m filing this as a desktop VS Code extension bug (Python extension loads, but Jedi LSP fails to initialize).
Related issue in the Jedi language server repository:
pappasam/jedi-language-server#351
Hello,
I’m experiencing a persistent problem with the Python extension in VSCodium when using the Jedi language server. The Python language server fails to initialize and keeps restarting, with the following error in the Output panel:
text
Server initialization failed.
Error: Unsupported position encoding (PositionEncodingKind.Utf16) received from server Python Jedi
at P.doInitialize (...\ms-python.python-2025.20.1-universal\out\client\extension.js:2:2084342)
at async P.start (...\ms-python.python-2025.20.1-universal\out\client\extension.js:2:2083020)
at async l.start (...\ms-python.python-2025.20.1-universal\out\client\extension.js:2:22276)
[...]
The Python Jedi server crashed 5 times in the last 3 minutes. The server will not be restarted.
From the source code, it looks like the client does a strict check on result.capabilities.positionEncoding:
ts
if (result.capabilities.positionEncoding !== undefined &&
result.capabilities.positionEncoding !== PositionEncodingKind.UTF16) {
throw new Error(Unsupported position encoding (${result.capabilities.positionEncoding}) received from server ${this.name});
}
In my case the server reports PositionEncodingKind.Utf16, and the client still throws and stops the server.
Environment
Editor: VSCodium (latest stable at the time of writing)
Python extension: ms-python.python-2025.20.1-universal
OS: Windows 10 x64
Python versions installed: 3.11, 3.12, 3.13, 3.14, 3.15 (user installs)
Active interpreter in workspace: Python 3.12 (venv)
Steps to reproduce
Install VSCodium.
Install the official Python extension (ms-python.python) from VSIX.
Open any Python project and let the extension start the Jedi language server (default settings).
Check the “Python” Output channel: the error above is printed, and language features do not work.
What I tried
Toggling python.jediEnabled and python.languageServer settings.
Disabling other Python‑related extensions.
Creating a fresh workspace and venv.
The problem persists as long as the Jedi LSP client is enabled.
Additional logs
text
2026-01-03 01:02:25.220 [info] [Error - 1:02:25 AM] Python Jedi client: couldn't create connection to server.
2026-01-03 01:02:25.220 [info] Error: Unsupported position encoding (PositionEncodingKind.Utf16) received from server Python Jedi
at P.doInitialize (c:\Users\ai.vscode-oss\extensions\ms-python.python-2025.20.1-universal\out\client\extension.js:2:2084342)
at async P.start (c:\Users\ai.vscode-oss\extensions\ms-python.python-2025.20.1-universal\out\client\extension.js:2:2083020)
2026-01-03 01:02:25.221 [info] [Error - 1:02:25 AM] Restarting server failed
2026-01-03 01:02:25.221 [info] Error: Unsupported position encoding (PositionEncodingKind.Utf16) received from server Python Jedi
at P.doInitialize (c:\Users\ai.vscode-oss\extensions\ms-python.python-2025.20.1-universal\out\client\extension.js:2:2084342)
at async P.start (c:\Users\ai.vscode-oss\extensions\ms-python.python-2025.20.1-universal\out\client\extension.js:2:2083020)
2026-01-03 01:02:27.345 [info] [Error - 1:02:27 AM] The Python Jedi server crashed 5 times in the last 3 minutes. The server will not be restarted. See the output for more information.
2026-01-03 01:02:27.351 [info] [Error - 1:02:27 AM] Server process exited with code 1.
Reference
Relevant client code in vscode-languageserver-node that throws on positionEncoding mismatch:
https://github.com/microsoft/vscode-languageserver-node/blob/main/client/src/common/client.ts
(quoted here for convenience):
ts
if (result.capabilities.positionEncoding !== undefined &&
result.capabilities.positionEncoding !== PositionEncodingKind.UTF16) {
throw new Error(Unsupported position encoding (${result.capabilities.positionEncoding}) received from server ${this.name});
}
Questions
Is this a known compatibility issue between the current Python extension and the Jedi language server in VSCodium?
Is there a recommended workaround (other than completely disabling the Python language server), e.g. a specific version of the extension or a configuration that relaxes the positionEncoding check?
Are there any plans to support PositionEncodingKind.Utf16 (or to make the check more tolerant) in future releases?
Any guidance would be appreciated. I’m setting up a public Python project and would like to keep using VSCodium if possible.
Thank you!
Best regards,
Activity
Artoria2e5 commentedon Jan 28, 2026
Add. Repro.
I did not encounter this issue with Python extension itself, but I got it with the other extensions:
Analysis
This is a bit of a headscratcher since everything is supposed to handle Utf16. That said, the definition should be the literal string "utf-16": https://github.com/microsoft/vscode-languageserver-node/blob/d85f305752dd88e0607206ca70baf7bf76ae6f79/protocol/src/common/protocol.ts#L981
Since we're seeing "PositionEncodingKind.Utf16" being thrown from
Unsupported position encoding (${result.capabilities.positionEncoding}) received from server ${this.name}, then this suggests that theresult.capabilities.positionEncodingis somehow the literal string"PositionEncodingKind.Utf16". Which makes no sense!Something must be broken at the LSP level, but I failed to find which by code search.
Utf16is how the python LSP end capitalizes the enum, but I don't see how it can get sent on the wire without being converted to the value.eleanorjboyd commentedon Jan 28, 2026
Karthik Nadig (@karthiknadig) any ideas here?
karthiknadig commentedon Jan 28, 2026
This might either be an issue with the version of pygls used with the server, if the same error shows up in multiple places.
Artoria2e5 commentedon Jan 29, 2026
I hand-edited
C:\Users\arthu\.vscode\extensions\ms-python.isort-2025.0.0\bundled\tool\lsp_server.pyto add(is there a better way to do this?)
This time I got
python/cpython#106309
This is not necessarily related to the current problem. Anyways I patched it out by substituting
in typing_extensions (upstream has a better fix, upgrade your deps!)
I then relaunched vscode. This time I get a better view of the events:
irrelevant part
It is therefore confirmed that the literal string "PositionEncodingKind.Utf16" was sent.
Finding the blame
I did the following logging at
ServerCapabilitiesBuilder.__init__():This time I noticed:
The client capabilities was therefore passed into
ServerCapabilitiesBuilderintact as"utf-16". Thepygls.protocol.language_server:Server capabilitieslogging does include the unwantedPositionEncodingKind.Utf16string, but is it representative of what the jsonrpc part does?Well, looks like it. What could've caused it though?
JSONRPCProtocol._serialize_message()has a check for enum. I did the following printing:Nothing odd here. Perhaps we should print the thing before dumping to compare?
Huh, not triggered here. Hey how did
position_encodingbecomepositionEncoding? Attr magic? This reminds me of the special casing in_serialize_message():What's a converter? Hmmm it's constructed from a
default_converterinBaseLanguageClient. Hmm it has something to do with cattrs, which according to its doc should only ever unstructure to value. This is beyond my ability to solve things by logging and I'm too hungry to continue.Artoria2e5 commentedon Jan 29, 2026
Some more logging injected at the same place
Now this just doesn't make sense. That's not what their doc (https://catt.rs/en/stable/defaulthooks.html#enums) says. This is not what cattrs/converter.py says for
(lambda t: issubclass(t, Enum), self._unstructure_enum),.Perhaps I should work on a minimal repro.
gives
Now we see the problem. Still, how?
antoshik86 commentedon Jan 31, 2026
I’d like to summarize what seems to be going on and suggest a concrete fix.
From Mingye Wang (@Artoria2e5)’s investigation, the root cause appears to be how pygls/cattrs serialize enums of the form class PEK(str, Enum) in server capabilities. Instead of sending the enum value (e.g. "utf-16"), the JSON produced on the wire ends up containing the enum member name (e.g. "PEK.Utf16"). This violates the LSP expectation for positionEncoding, which must be the literal string "utf-16", so the VS Code Python client is correct to reject it as an unsupported encoding.
In the minimal repro, two enum definitions behave differently under cattrs:
python
@enum.unique
class PEK(str, enum.Enum):
Utf8 = "utf-8"
Utf16 = "utf-16"
Utf32 = "utf-32"
@enum.unique
class PEK2(enum.Enum):
Utf8 = "utf-8"
Utf16 = "utf-16"
Utf32 = "utf-32"
For PEK, cattrs.unstructure(...) ends up producing "PEK.Utf16" in JSON, while for PEK2 the output is the correct "utf-16". This matches what we see on the wire for positionEncoding.
Given that, there are two straightforward ways to fix this on the server side:
Change PositionEncodingKind (and any similar enums used in server capabilities) from class PositionEncodingKind(str, Enum) to a plain Enum:
python
class PositionEncodingKind(enum.Enum):
Utf8 = "utf-8"
Utf16 = "utf-16"
Utf32 = "utf-32"
This makes cattrs serialize positionEncoding as "utf-16", which is what the LSP spec and vscode-languageserver-node expect.
Alternatively, keep the existing enum definition, but register a custom unstructure hook for this type (or add a generic hook in pygls), ensuring that cattrs always emits enum.value instead of the member name. For example:
python
from pygls.protocol import default_converter
conv = default_converter()
conv.register_unstructure_hook(PositionEncodingKind, lambda e: e.value)
Either approach should make the server send "utf-16" as the positionEncoding capability and restore compatibility with the VS Code Python extension (and other LSP clients that perform a strict check on this field).
I’m happy to test a patched build of jedi-language-server/pygls in my VSCodium setup as soon as a change is available.
antoshik86 commentedon Feb 3, 2026
I can confirm that patching the
PositionEncodingKindclass definition locally fixes the issue on Windows immediately.For anyone who needs a quick fix without downgrading, I used a PowerShell script to locate and patch the file in the installed extension.
The Fix:
It finds
lsprotocol/types.pyinside the installedms-python.pythonextension and changes:Artoria2e5 commentedon Feb 3, 2026
I kinda want to @ the cattrs author in here and ask about what the right way to fix this is, but I'm afraid of coming across too rude Well....