You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
PrepareRename throws NullReferenceException when an LSP client omits the rename capability (v4.6.0) #2297
In PSES v4.6.0, an LSP initialize whose capabilities.textDocumentomits rename leaves the prepare-rename handler dereferencing a null client RenameCapability. Observed effect: the server never returns an initialize
response (the handshake hangs) and the PSES log records a NullReferenceException
on the rename-handler path.
Declaring even a minimalrename capability avoids it and the handshake
completes normally. This inverts the usual expectation that omitting an optional
client capability is always safe, so it is easy to hit from a minimal or hand-rolled
LSP client.
The handshake now completes and diagnostics flow. The only difference is the
presence of the rename capability object.
Expected
Omitting the optional rename capability must not break initialize. The
prepare-rename handler should null-guard the client RenameCapability (treat absent
as "client does not support rename") rather than dereferencing it.
Context
Found while building a Claude Code plugin that drives PSES over stdio
(https://github.com/manderse21/claude-powershell-lsp). The plugin now declares a
minimal rename capability specifically to dodge this, but the root cause should be
fixed for any client that legitimately omits it.
I feel like I had something similar happen in the Zed extension for PowerShell but I couldn't get LSP trace out of it. I'll try to do a review of the PR.
Activity
andyleejordan commentedon Jun 8, 2026
If my understanding is correct I believe this is resolved by #2296
JustinGrote commentedon Jun 9, 2026
I feel like I had something similar happen in the Zed extension for PowerShell but I couldn't get LSP trace out of it. I'll try to do a review of the PR.
Thanks for the submission Mike Andersen (@manderse21)! Harass me if I don't review it by 6/15
JustinGrote commentedon Jun 11, 2026
Agreed, closing in favor of #2296 as I like the approach better. Thanks for your submission however!