# PowerShell Editor Services: one language server for every PowerShell editor

> PowerShell Editor Services is the C# engine that gives editors IntelliSense, navigation, script analysis, debugging and a $psEditor API for PowerShell, exposed over the Language Server Protocol so any compliant client can use it. Connecting it over named pipes rather than stdio is what makes the debugger and the Extension Terminal available, and the project warns that its own editor extensions are community maintained and can be far out of date.

**PowerShell/PowerShellEditorServices** — A common platform for PowerShell development support in any editor or application!

- Repository: https://github.com/PowerShell/PowerShellEditorServices
- Stars: 776 · Forks: 267
- Language: C#
- License: MIT
- Published: 2026-10-21 · Updated: 2026-10-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/powershell-powershelleditorservices

## What PowerShell Editor Services is separated from the VS Code extension

The project describes itself as a PowerShell module that provides common functionality needed to enable a consistent development experience in almost any editor or IDE. The key word there is module. PowerShell Editor Services runs inside a PowerShell host rather than inside the editor, which is what lets the same implementation back a dozen front ends.

The features it provides are grouped in three layers. The Language Service covers code navigation actions such as find references and go to definition, statement completions, and real-time semantic analysis of scripts using PowerShell Script Analyzer. The Debugging Service simplifies interaction with the PowerShell debugger, covering breakpoints, variables and call stack. The $psEditor API, documented in docs/guide/extensions.md, enables scripting of the host editor so an extension can drive the editor it is running in.

Beyond those, there is a full Extension Terminal for interactive development and debugging. Because the service is host-agnostic, a client integration is mostly a matter of spawning the right process and speaking the right protocol over the right stream.

## Named pipes versus stdio decides what you can ship

There are two ways to connect, and the choice is not a matter of taste. It determines which features exist in your product.

Named pipes, called sockets in the documentation, are described as the way to go for a more feature-rich experience. They carry all the benefits of the Language Server Protocol plus the PowerShell Extension Terminal and debugging through the Debug Adapter Protocol. The Visual Studio Code, Vim, Neovim and IntelliJ extensions all use named pipes.

Stdio is called the simplest option in most LSP clients, and it is the one to pick when you only want the language features. The documentation is explicit about the cost: the debugger and the Extension Terminal are not available over stdio, because they require their own IO streams and stdio provides a single pair of streams. That constraint is architectural, and no configuration flag removes it.

There is a related detail for the Extension Terminal itself. It uses the host process stdio streams for console input and output, which is mutually exclusive from using stdio for the Language Server Protocol messages. To get it you must pass the -EnableConsoleRepl switch to Start-EditorServices.ps1, and the transport for the protocol messages has to move elsewhere.

## Starting the server with the two transport options

The typical launch command for the named pipe mode passes a session details path, and the server writes the pipe names it created into that file so the client knows where to connect:

```bash
pwsh -NoLogo -NoProfile -Command "./PowerShellEditorServices/Start-EditorServices.ps1 -SessionDetailsPath ./session.json"
```

For stdio the command adds the -Stdio switch and a log level:

```bash
pwsh -NoLogo -NoProfile -Command "./PowerShellEditorServices/Start-EditorServices.ps1 -Stdio -LogLevel Error"
```

Two practical notes from the documentation. The start script is found in the PowerShellEditorServices folder rather than in the PowerShellEditorServices.zip downloaded from the GitHub releases, so the path in the command depends on how you unpacked the archive, and the given command assumes the current directory is the folder where you expanded the ZIP. Second, depending on your editor you should set the environment variables NO_COLOR and TERM before issuing the command, to improve the readability of error messages pwsh may output.

After the command runs, the service waits until a client connects to the named pipe. The session.json contains the pipe paths, one for Language Server Protocol messages that you connect to immediately, and another you connect to when you launch the debugger for Debug Adapter Protocol messages.

## Driving the service from PowerShell with Start-Process

If you are automating the service from PowerShell rather than letting an editor spawn it, the documentation recommends running it under Start-Process to prevent hanging your script, and notes that this gives access to process automation features such as $process.Close() or $process.Kill().

The full argument set is shown here as the project documents it:

```bash
$command = @(
    "$PSES_BUNDLE_PATH/PowerShellEditorServices/Start-EditorServices.ps1",
        "-BundledModulesPath $PSES_BUNDLE_PATH",
        "-LogPath ./logs",
        "-SessionDetailsPath ./session.json",
        "-FeatureFlags @()",
        "-AdditionalModules @()",
        "-HostName 'My Client'",
        "-HostProfileId 'myclient'",
        "-HostVersion 1.0.0",
        "-LogLevel Trace"
) -join " "
```

Two observations. The command is assembled as an array joined with spaces, so the quoting of each element matters when the whole thing is passed to -Command. And the parameters show the shape of the integration contract: the client identifies itself with -HostName, -HostProfileId and -HostVersion, and controls behaviour with -FeatureFlags and -AdditionalModules.

The documentation also states that Start-EditorServices.ps1 takes many more optional arguments, but that they no longer need to be specified. That is a compatibility note for older integrations, and it means the argument list above is the current minimum rather than the full surface.

## Version support and the state of the editor extensions

PowerShell Editor Services runs as a PowerShell module in currently supported versions of PowerShell 7 plus, following the published support lifecycle. Windows PowerShell 5.1 is supported on a best-effort basis, which is a different promise and should be read as one.

The client ecosystem deserves a careful read. The project lists lsp-pwsh for Emacs, intellij-powershell for IntelliJ-based IDEs, coc-powershell for Vim and Neovim, and powershell.nvim for Neovim, but it puts a warning on that list: these clients are community maintained and may be very out of date. Its recommendation is to use a generic LSP plugin with your client if possible.

There is also a deprecation notice. PowerShell for Azure Data Studio will no longer be updated or maintained, while PowerShell for Visual Studio Code is the reference client that continues to be developed against this project.

So the practical picture is a well-supported core with a mixed client layer. If you are writing your own client, base it on the protocol and on the tested configurations rather than on any single community plugin.

## Tested end-to-end configurations live in the test folder

For anyone integrating a client, the most useful thing in the repository is the set of end-to-end test configurations, which the documentation points to: emacs-simple-test.el, emacs-test.el, vim-simple-test.vim and vim-test.vim. They exercise real editors driving the server, which is a different level of confidence than a unit test of a protocol handler.

The Emacs tests use eglot for Emacs, and the Vim tests use LanguageClient-neovim. Those two clients are therefore the reference implementations you can copy from, and the files are readable in a way that a protocol specification is not. Since the earlier sections describe a service that must be launched with the right transport, the right pipe paths and the right client identity flags, having a working configuration to diff against saves a lot of guesswork.

The repository also carries the usual surrounding structure for a project of this kind: a solution file PowerShellEditorServices.sln, Directory.Build.props and Directory.Packages.props, a build script PowerShellEditorServices.build.ps1, a global.json, nuget.config, and separate module/, src/, test/ and docs/ directories. There is a CHANGELOG.md and a SECURITY.md, plus the extension documentation at docs/guide/extensions.md that the $psEditor API section depends on.

## MIT licensed, and moving at a monthly release cadence

The project is released under the MIT licence, with the licence text in the LICENSE file and a separate NOTICE.txt at the root of the repository. Both are in the tree, and the NOTICE file means the terms include any attribution the upstream contributors require, so a distributor should copy both files rather than only the licence.

The release history shows a steady monthly sequence, with v4.7.0 on 2026-06-25, v4.6.0 on 2026-05-16 and v4.5.0 on 2026-04-08. The repository is not archived, and the last push was on 2026-10-15.

The version number matters more here than in a typical library. Since PowerShell Editor Services is a server process that a client launches, the client and the server have to agree on the protocol behaviour they expect. A client that upgrades on its own schedule against a server that has moved on is where breakage shows up, so the version pair in the session details and the client host version are worth tracking as a unit rather than separately.

## Conclusion

Adopt PowerShell Editor Services if you are building or maintaining a PowerShell editor outside the Visual Studio Code extension, or if you want the same language features across several clients from one server process, because connecting over named pipes gives you the Debug Adapter Protocol and the Extension Terminal that stdio cannot carry. Do not adopt it if your client is limited to stdio and you need breakpoints, since the debugger requires its own IO streams. Before you build against it, confirm the host runs a currently supported PowerShell 7 plus release rather than Windows PowerShell 5.1, which is supported only on a best-effort basis, and check that the start script path in your launch command matches where you unpacked the ZIP, since Start-EditorServices.ps1 lives in the PowerShellEditorServices folder of the archive.

## FAQ

### How do I start PowerShell Editor Services for an LSP client?

The documented stdio command is pwsh -NoLogo -NoProfile -Command "./PowerShellEditorServices/Start-EditorServices.ps1 -Stdio -LogLevel Error". The path assumes the current directory is where you expanded the PSES ZIP, since the start script lives in the PowerShellEditorServices folder rather than in the downloaded zip.

### Why is the debugger unavailable over stdio in PowerShell Editor Services?

The debugger and the Extension Terminal require their own IO streams, and stdio provides only a single pair of streams. To get them you need the named pipe transport and the -EnableConsoleRepl switch, and the Extension Terminal is mutually exclusive with using stdio for the Language Server Protocol messages.

### Which PowerShell versions does PowerShell Editor Services support?

It runs as a PowerShell module in currently supported versions of PowerShell 7 plus. Windows PowerShell 5.1 is supported on a best-effort basis, which is a weaker commitment than the PowerShell 7 plus line.

### Which editors can use PowerShell Editor Services?

The project lists an Emacs plugin, an IntelliJ plugin, a Vim and Neovim plugin and a Neovim plugin, but warns that these clients are community maintained and may be very out of date. It recommends using a generic LSP plugin with your client if possible, and tested end-to-end configurations are provided for Emacs with eglot and for Vim with LanguageClient-neovim.

### What does the $psEditor API in PowerShell Editor Services do?

It enables scripting of the host editor, so an extension running inside PowerShell Editor Services can drive the editor it is hosted in. The API is documented in docs/guide/extensions.md in the repository.

## Sources

- [Issues](https://github.com/PowerShell/PowerShellEditorServices/issues)
- [License: MIT](https://github.com/PowerShell/PowerShellEditorServices/blob/main/LICENSE)
- [PowerShell/PowerShellEditorServices on GitHub](https://github.com/PowerShell/PowerShellEditorServices)
- [README](https://github.com/PowerShell/PowerShellEditorServices/blob/main/README.md)
- [Releases](https://github.com/PowerShell/PowerShellEditorServices/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/powershell-powershelleditorservices