I found this in Helix log:
2026-10-09T16:38:29.278 helix_lsp::transport [ERROR] roc-experimental <- ServerError(-32803): Semantic features require initializationOptions.trustedWorkspace: true; restart the server after granting trust.
This is very bad UX.
I don't see anything in the Helix interface, I have to dig through logs.
I don't even know whether it's some Roc setting to tweak, or a Helix setting.
Is there some documentation about it?
It's in a project that I developed from scratch, not something I downloaded.
It's probably to do with this PR. I don't use Helix, but I suspect the command :workspace-trust might be what you need
Yes I picked this up in a review of CVE's as something we should fix to prevent untrusted codebases doing nefarious things through the LSP
Thanks, @Jonathan. That's it. I'm using the stable release of Helix, which does not have this feature yet, so it was not showing the trust modal nor the warning sign.
Is it possible to detect the editor name from the LSP?
Since many users are using the latest stable Helix, which does not have the "workspace trust" feature, maybe a window/showMessage could help them understand what's happening, and how they can resolve it.
I'm using the stable release of Helix, which does not have this feature yet, so it was not showing the trust modal nor the warning sign.
there might be some way in LSP to do feature detection?
There is, but I think this workspace trust thing is not detectable via that.
The unfortunate thing is that Helix has been abandoned by its original author, so no new releases can be expected, and I don't know how much time it takes for Linux distros to switch to a maintained fork.
ok so let's say we communicate it via a message...what would Helix users be able to do?
I just hardcoded the trust value into the Roc LSP initial settings:
[language-server.roc-experimental]
command = "roc"
args = ["experimental-lsp"]
config = { "trustedWorkspace" = true }
Explaining this is not doable via a simple message. I recommend directing them towards some kind of documentation page.
Helix does not support workspace trusting yet. Compile Helix from the
masterbranch, or see https://roc-lang.org/helix for workaround on stable release.
But this is too long, maybe just print the link:
To enable semantic analysis, see https://roc-lang.org/helix for instructions.
that seems reasonable, although I'd like to have the link go somewhere else...I don't really want to have a roc-lang.org/helix page indefinitely :sweat_smile:
Not needed indefinitely, just until a new Helix release or most of the distros switching to the maintained unofficial fork.
But I understand the concern.
Could use any URL shortener instead, pointed to a GitHub Pages link.
But the official domain signals trust.
Is there any “editor support” page at all in the documentation?
New tools/languages usually include one.
not currently, but I guess we could add a section
See these for example:
https://biomejs.dev/configuration/editors/
https://zine-ssg.io/docs/editors/
Would you better agree to a https://roc-lang.org/editors/helix link?
I guess N is pretty small for total number of editors we'd have on there, so yeah let's go for it :thumbs_up:
I'll put together a guide for Helix.
@notramo we could add something to https://github.com/lukewilliamboswell/roc-awesome
The lack of development activity around Helix is quite annoying, and many users feel this way. Unfortunately, it's putting the burden on projects like Roc and other languages.
Setting up Roc on a clean Helix config is a task on its own.
probably worth adding to the new page then!
if anyone wants to make a PR to the website to just get some information up there, we can figure out the styling etc in follow-ups
Last updated: Oct 15 2026 at 17:56 UTC