-
Notifications
You must be signed in to change notification settings - Fork 10
Description
Description
PowerShellEditorServices (PSES) fails to complete LSP initialization when Zed runs natively on Windows, even though the server process starts successfully.
However, running Zed inside WSL on the same machine, using the default Zed configuration, works correctly without any changes. This strongly suggests the issue is specific to Zed’s Windows LSP process handling rather than PowerShellEditorServices itself or this extension.
I am reporting this here first in case the extension maintainer has insight or can help escalate the issue upstream to Zed.
Environment
Failing case
- OS: Windows 10 / 11 (native)
- Zed: latest stable (Windows build)
- PowerShell: pwsh 7.5.4
- Extension: zed-powershell
Working case
- OS: WSL (same host machine)
- Zed: latest stable Windows build (running inside WSL)
- PowerShell: pwsh 7.5.4
- Configuration: default
- Extension: zed-powershell
Expected behavior
- Zed sends the LSP initialize request over STDIN
- PSES processes it and responds
- LSP session initializes successfully
Current behavior (Windows only)
- SES process starts successfully
- No LSP traffic appears in PSES logs
- Zed times out LSP initialization
- Server appears idle, as if STDIN input is not received
Manual validation
When the same PSES startup command is executed manually and a valid LSP initialize request is sent over STDIN, PSES responds correctly.
This confirms:
- PSES works over raw STDIO
- The startup command is valid
- The failure only occurs when Zed launches the process on Windows
This strongly points to a Windows-specific issue in Zed’s LSP process spawning or STDIO wiring (pipes vs PTY, buffering, or encoding).
Questions for maintainers
- Is there anything in the extension that could behave differently on Windows vs Linux?
- Are you aware of other STDIO-based language servers failing only on Windows in Zed?
- Would it be appropriate to open or link a corresponding issue in the Zed core repository?