Does Helix Support Plugins?
Updated
No. Helix does not currently have a plugin system. The project's own FAQ states that while there is no plugin system available today, the maintainers do intend to add one eventually — but it "will take some time," and the discussion is tracked on GitHub rather than on a published roadmap with dates.
That single fact answers the direct question, but it raises a practical one: if you can't extend Helix with plugins, what can you actually configure or rely on? The rest of this page covers what Helix ships with instead, and how to judge whether the missing plugin system matters for your workflow.
What "no plugin system" means in practice
In editors like Vim, Neovim, or VS Code, a large share of functionality arrives through third-party plugins: file trees, Git integration, fuzzy finders, language-specific tooling, and so on. Helix takes the opposite approach. Its FAQ explicitly contrasts itself with Kakoune by saying Helix "chooses to integrate more" — features that other editors delegate to external tooling or plugins are built in.
So the absence of plugins is not the same as the absence of features. It means you cannot add arbitrary third-party functionality, and you cannot write your own extensions in a scripting language, because there is no plugin API to target.
What Helix provides without plugins
According to the project's homepage, the following are built-in:
- Multiple selections — multiple cursors as a core editing primitive, inspired by Kakoune, where commands manipulate selections to allow concurrent editing.
- Tree-sitter integration — error-tolerant syntax trees used for syntax highlighting, indent calculation, and code navigation.
- Structural code manipulation — navigate and select functions, classes, comments, and other syntax tree nodes rather than plain text.
- Language server support — auto-completion, goto definition, documentation, and diagnostics, described as requiring "no additional configuration."
- Built-in utilities — fuzzy finder for files and symbols, project-wide search, themes, auto-closing bracket pairs, and surround integration.
The implementation detail matters here: Helix is built in Rust for the terminal, with no Electron, no VimScript, and no JavaScript. It runs over ssh, tmux, or a plain terminal. That design choice is part of why there is no scripting-based plugin layer — there is no embedded scripting runtime to extend.
How this compares to editors with plugin ecosystems
| Editor | Plugin system today | Extension mechanism |
|---|---|---|
| Helix | No | None available; built-in features only |
| Kakoune | Not in the same sense | Composable by design, relying on external tooling for splits and language server support |
| Vim / Neovim | Yes | Scripting and third-party plugins |
The Kakoune comparison is the most useful one, because both editors share the multiple-selection editing model. The difference, per Helix's FAQ, is that Kakoune expects you to assemble functionality from external tools, while Helix bundles it. If you are coming from Kakoune, you gain built-ins but lose the composability that comes from wiring tools together yourself.
Should the missing plugin system change your decision?
It depends on what you need:
- Choose Helix if the built-in set covers your work — modal editing with multiple selections, Tree-sitter highlighting and navigation, and LSP features without configuration. The FAQ's blunt answer to "Is it any good?" is simply "Yes."
- Avoid Helix for now if your workflow depends on a specific plugin, on writing your own extensions, or on a GUI. A GUI frontend is also only planned: the FAQ says "eventually, yes," with interest in prototyping a WebGPU-based alternative frontend, discussed on GitHub.
What to watch if you're waiting for plugins
Two things are explicitly framed as future work rather than shipped features: the plugin system and the GUI frontend. Both are described as eventual goals with ongoing GitHub discussion, and the plugin entry adds the caveat that it "will take some time." There is no stated timeline in the project's own material, so treat any specific date you see elsewhere as unverified.
If plugin support is a hard requirement for adopting an editor, Helix is not the right fit yet. If you mainly want a terminal editor with strong built-in defaults and less configuration fiddling, the missing plugin system may not affect you at all.