LSP client doesn't support confirmation

[wavesinaroom]

Hi!

I'm writing an LSP for a music language that isn't available as a stand alone application. This is the beginning of the project and I want to test my first message sent from the server to Helix. Problem is that Helix complains about not having confirmation support from my server. This is what I got from the editor:

Your LSP client doesn't support confirmation. You can enable autoArchive in lsp configuration.

I went through Helix documentation language section a couple of times but I didn't see that option anywhere. Then I thought that maybe that option is in the lsp specification but it wasn't there either. Now that read Helix output Your LSP client catches my attention. If Helix is the client, why doesn't it support confirmation, that's baffling. Can anyone lend me a hand with a clue on this please?

[waddie]

I don’t think that’s a Helix error message. The text doesn’t appear anywhere in the source code.

There’s an exact match in nil, the Nix language server. I don’t know Nix, nor how or why it’s interacting with the LSP you’re developing, but I’d look there first. A similar issue was reported for zed, maybe you just need to run nix flake archive manually?

[wavesinaroom]

Thanks a lot! Yeah I'm using Home manager on Fedora so this issue has to do with it. I'll check that more in depth

[kaminagakur4]

The answer to your literal question is that Helix does support it, but no released Helix advertises it, and that matters for the server you're writing.

nil picks its branch on one exact field of initialize: window.showMessage.messageActionItem.additionalPropertiesSupport. I put a proxy on the wire against the official helix-25.07.1-aarch64-macos binary and capabilities.window comes across as exactly {"workDoneProgress": true}. No showMessage key at all, in any config shape I tried.

The capability does exist in the source. It's in helix-lsp/src/client.rs around line 748, show_message: Some(ShowMessageRequestClientCapabilities { message_action_item: ... }). It just isn't in anything you can download. It came in with commit 76c23b306, "Support LSP workspace/showMessageRequest", which was authored 2025-07-11 but only landed on master 2026-01-25. The newest release, 25.07.1, went out 2025-07-18, six months before that. git grep message_action_item 25.07.1 returns nothing.

So for your own Go server: against any current release, window/showMessageRequest with action items won't get you the picker either. You'll get the plain message and no selection. If that's the feature you were about to test, build Helix from master or you'll be debugging your server for a client behaviour that isn't shipped yet.

For the flake warning itself, @waddie is right that it's nil's message. The fix that doesn't need a rebuild is to let nil archive the flake for you, in languages.toml:

[language-server.nil]
command = "nil"

[language-server.nil.config.nix.flake]
autoArchive = true

Note the key sits at the top of config, not nested under "nil". Helix sends config verbatim as initializationOptions, and nil applies those with JSON pointers starting at /nix/.... The nested form that nil's README documents does eventually resolve, through workspace/configuration, but it arrives too late here: a non-empty initializationOptions object makes nil kick off the flake load during initialize, while nix_flake_auto_archive is still unset, so the warning has already fired by the time the configuration reply comes back and nothing re-runs the load.

Measured on helix 25.07.1 (a05c151) and nil, with a real .nix file open.

[wavesinaroom]

Hi!

Thanks for your reply! I was confused with my lop messages but it's clearer now. I just started learning about LSP and it has shown me that being a Helix user is a different experience to developing something for it. I guess this is the beauty of open source projects like Helix. On one hand you use it but your perspective on it changes when you work on it as a product.

Learned something new today, thanks for that :)

[kaminagakur4]

Glad it helped. Your logs were doing their job, they just weren't reporting on your code. That algorithm complaint was nil talking about LINE's tokens, which is a confusing place to land when you're looking for your own server's output.

One habit worth picking up early, now that you're on the server side: log the client capabilities you receive in initialize and keep them where you can read them. Every client advertises a different subset, and a good share of "why isn't my feature showing up" in LSP turns out to be the client quietly saying it doesn't support that thing. It's the same shape as what caught you here, just seen from the other end of the wire.

And for what you originally set out to do, plain window/showMessage has no capability gate on it at all. Helix handles it on the release you already have (helix-term/src/application.rs, the Notification::ShowMessage arm). Server sends, editor shows. So if you want your first server-to-client message to land today, that's the one to reach for, and you can keep showMessageRequest for whenever you build from master.

Good luck with the server!!

[wavesinaroom]

Thanks again!