notramo (Oct 09 2026 at 14:41): notramo (Oct 09 2026 at 14:41):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.
notramo (Oct 09 2026 at 14:41):This is very bad UX.
notramo (Oct 09 2026 at 14:42):I don't see anything in the Helix interface, I have to dig through logs.
notramo (Oct 09 2026 at 14:42):I don't even know whether it's some Roc setting to tweak, or a Helix setting.
notramo (Oct 09 2026 at 14:44):Is there some documentation about it?
notramo (Oct 09 2026 at 14:45):It's in a project that I developed from scratch, not something I downloaded.
Jonathan (Oct 09 2026 at 15:51):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
Luke Boswell (Oct 09 2026 at 17:07):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
notramo (Oct 09 2026 at 17:07):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.
notramo (Oct 09 2026 at 19:32):Is it possible to detect the editor name from the LSP?
notramo (Oct 09 2026 at 19:33):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.
Richard Feldman (Oct 09 2026 at 20:34):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?
notramo (Oct 09 2026 at 20:35):There is, but I think this workspace trust thing is not detectable via that.
notramo (Oct 09 2026 at 20:40):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.
Richard Feldman (Oct 09 2026 at 20:45):ok so let's say we communicate it via a message...what would Helix users be able to do?
notramo (Oct 09 2026 at 20:46):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.
notramo (Oct 09 2026 at 20:48):Helix does not support workspace trusting yet. Compile Helix from the
masterbranch, or see https://roc-lang.org/helix for workaround on stable release.
notramo (Oct 09 2026 at 20:50):But this is too long, maybe just print the link:
To enable semantic analysis, see https://roc-lang.org/helix for instructions.
Richard Feldman (Oct 09 2026 at 20:51):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:
notramo (Oct 09 2026 at 20:52):Not needed indefinitely, just until a new Helix release or most of the distros switching to the maintained unofficial fork.
notramo (Oct 09 2026 at 20:52):But I understand the concern.
notramo (Oct 09 2026 at 20:52):Could use any URL shortener instead, pointed to a GitHub Pages link.
notramo (Oct 09 2026 at 20:52):But the official domain signals trust.
notramo (Oct 09 2026 at 20:55):Is there any “editor support” page at all in the documentation?
notramo (Oct 09 2026 at 20:55):New tools/languages usually include one.
Richard Feldman (Oct 09 2026 at 20:55):not currently, but I guess we could add a section
notramo (Oct 09 2026 at 20:56):See these for example:
https://biomejs.dev/configuration/editors/
https://zine-ssg.io/docs/editors/
notramo (Oct 09 2026 at 20:57):Would you better agree to a https://roc-lang.org/editors/helix link?
Richard Feldman (Oct 09 2026 at 21:00):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:
notramo (Oct 09 2026 at 21:03):I'll put together a guide for Helix.
Luke Boswell (Oct 09 2026 at 21:03):@notramo we could add something to https://github.com/lukewilliamboswell/roc-awesome
notramo (Oct 09 2026 at 21:07):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.
notramo (Oct 09 2026 at 21:08):Setting up Roc on a clean Helix config is a task on its own.
Richard Feldman (Oct 09 2026 at 23:03):probably worth adding to the new page then!
Richard Feldman (Oct 09 2026 at 23:03):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
BearCarpenter (Oct 16 2026 at 19:31):I can confirm this also affected VS Code with the IvanDemchenko.roc-lang-unofficial extension.
fix:
https://github.com/ivan-demchenko/roc-vscode-unofficial/pull/51#issue-5889926474
Anton (Oct 17 2026 at 07:42):I am working on an official vscode roc extension so that we can immediately fix issues.
Luke Boswell (Oct 17 2026 at 11:20):@Anton I forked and upgraded @Hannes one and that is basically 100% done.
Luke Boswell (Oct 17 2026 at 11:22):I think he's been porting my work across and plans to publish that. I havent looked at it in a while, but Id love for someone to publish something that is maintained and supports the latest syntax so we can update github highlighting
Anton (Oct 17 2026 at 13:22):publish something that is maintained and supports the latest syntax so we can update github highlighting
Yes, that is the goal :)
Anton (Oct 17 2026 at 13:24):I will compare my PR with your repo and Hannes' repo to understand the different trade-offs they have made. @Luke Boswell do you think it's a good idea that we make an official extension under https://github.com/roc-lang/roc?
gavr (Oct 17 2026 at 17:52):Same for Zed, I can see this error only in RCP logs, very bad UX, no error message, or explanation how to actually grant trust.
When I do workspace: toggle worktree security it doesn't change anything.
Luke Boswell (Oct 17 2026 at 18:45):If we can avoid making an official one, that would be better ... but I'm not sure.
It's another thing to maintain and we have limited resources. One potential concern would be that everyone defaults to that and there isn't any opportunity for others to really innovate and build nicer experiences. I dont know how much innovation there is in editor tooling like this for a language though.
On the other hand GitHub syntax highlighting is something we care about getting right, and if Ivan isn't accepting PR's or happy to add other contributors to help him maintain that, then we will need another repository that is actively maintained.
Anton (Oct 18 2026 at 07:38):I don't know how much innovation there is in editor tooling like this for a language though.
Yeah, I feel like just delivering a decent set of features that works well is already very valuable.
Anton (Oct 18 2026 at 09:13):I also think people like the trust that comes with an official extension.
gavr (Oct 21 2026 at 09:06):What is the current solution for Zed? I can't find a way to make "initializationOptions.trustedWorkspace: true"
notramo (Oct 21 2026 at 09:09):Maybe this the Zed option?
https://zed.dev/docs/worktree-trust
gavr (Oct 21 2026 at 19:24):nope, I already tried workspace: toggle worktree security, I think its the same.
Now tried to add
"session": {
"trust_all_worktrees": true
}
Same errors in RPC
{"code":-32803,"message":"Semantic features require initializationOptions.trustedWorkspace: true; restart the server after granting trust.","data":null}}
I also got it working again in nvim with this config (using lazy):
{
"neovim/nvim-lspconfig",
opts = {
servers = {
roc = {
cmd = { "roc", "experimental-lsp" },
filetypes = { "roc" },
init_options = {
trustedWorkspace = true,
},
mason = false,
},
},
},
}
I don't now if there are any official docs for neovim, at least I couldn't find it.
Anton (Oct 25 2026 at 18:07):Thanks for sharing the fix @Olav L, I will make an issue to add it on the website.
gavr (Oct 31 2026 at 20:01):Am I correct in understanding that LSP isn't working for anyone right now (at least in the Zed editor)?
notramo (Oct 31 2026 at 20:02):It works if you override the initialization options.
gavr (Oct 31 2026 at 20:02):how to do it exactly? I tried
notramo (Oct 31 2026 at 20:03):@Richard Feldman, could you help with the Zed integration?
Richard Feldman (Oct 31 2026 at 22:01):I haven't been following, sorry - what's the issue?
notramo (Oct 31 2026 at 22:02):LSP does not work in Zed.
notramo (Oct 31 2026 at 22:02):The Neovim/Helix workarounds are not applicable there.
Richard Feldman (Oct 31 2026 at 22:16):I need more specifics haha
Richard Feldman (Oct 31 2026 at 22:17):the are millions of people using LSP in Zed - do you mean the specific Roc one isn't working?
notramo (Oct 31 2026 at 22:17):I don't know the exact problem, as I haven't tried it in Zed. But as I understand, @gavr has trouble setting it up.
notramo (Oct 31 2026 at 22:17):Probably the workspace trust problem.
notramo (Oct 31 2026 at 22:18):The Helix/Neovim init option hack does not work in Zed.
notramo (Oct 31 2026 at 22:18):Or it's not trivial to set up.
Richard Feldman (Oct 31 2026 at 22:18):ok I'm happy to help if someone can give me a specific blocker that I can help remove, but this is not actionable right now haha
notramo (Oct 31 2026 at 22:19):How did you configure your Zed setup?
notramo (Oct 31 2026 at 22:19):I guess it would work for others too.
Richard Feldman (Oct 31 2026 at 22:19):I set it up a long time ago and I don't remember doing anything special
notramo (Oct 31 2026 at 22:20):But when the trusted workspace requirement was added, did it break your setup?
Richard Feldman (Oct 31 2026 at 22:20):@gavr since you're having the specific problem, can you give me some details on what the blocker or error you're running into is?
notramo (Oct 31 2026 at 22:21):Probably the one described here:
notramo (Oct 31 2026 at 22:22):Apparently the same error message in the logs as I found in Helix.
Jonathan (Nov 01 2026 at 01:34):@gavr Mine stopped when I updated, and this in my project settings seemed to fix it
"lsp": {
"roc": {
"initialization_options": {
"trustedWorkspace": true
}
}
},
@Richard Feldman yes, my problem is the same as in the first message of this thread, after the update roc lsp just stopped working, then I discover the reason in internal RCP messages
I thought it wasn't specific to me, Im using the only available extension for Roc in Zed, and Roc is installed via Homebrew (on macOS).
gavr (Nov 01 2026 at 19:09):Jonathan said:
gavr Mine stopped when I updated, and this in my project settings seemed to fix it
"lsp": { "roc": { "initialization_options": { "trustedWorkspace": true } } },
@Jonathan thank you, that works!
notramo (Nov 01 2026 at 19:18):So the workaround for every editor is to disable these protections.
notramo (Nov 01 2026 at 19:19):Basically we are back to where we were before, from a security perspective.
notramo (Nov 01 2026 at 19:19):But much-much worse from a UX perspective.
Jonathan (Nov 01 2026 at 19:48):In fairness, I have enabled this in my project settings, not my user settings.
Richard Feldman (Nov 01 2026 at 22:22):so did this settings change start being necessary because something in the Roc language server implementation changed?
notramo (Nov 01 2026 at 22:23):Yes.
notramo (Nov 01 2026 at 22:25):https://github.com/roc-lang/roc/pull/12096
Richard Feldman (Nov 01 2026 at 22:26):ahh right, I remember this
Richard Feldman (Nov 01 2026 at 22:27):ok I'll roll that back for now
notramo (Nov 01 2026 at 22:27):This would be an improvement, if editors properly supported these features. But none of the most popular ones support this.
notramo (Nov 01 2026 at 22:27):Therefore everyone just hardcoded the config to trust every workspace automatically.
Richard Feldman (Nov 01 2026 at 22:28):in theory those operations should be harmless aside from wasting disk space and/or heating up your CPU
notramo (Nov 01 2026 at 22:28):In practice, there could be exploits.
Richard Feldman (Nov 01 2026 at 22:29):yeah originating from compiler bugs etc
notramo (Nov 01 2026 at 22:29):But there's not really a difference between running the code in the LSP and running it in roc check or roc run.
Richard Feldman (Nov 01 2026 at 22:30):and regardless it seems like better practice to only download potentially large things from untrusted sources (and run arbitrarily cpu-intensive work) only with permission, but yeah if it's not implemented by clients in practice then not worth it for now :+1:
Richard Feldman (Nov 01 2026 at 22:30):I'll change it - can someone open an issue to track this and link to this conversation?
notramo (Nov 01 2026 at 22:32):Practically nobody does this specific workflow where this workspace trust feature would be an improvement:
roc check or roc run or roc build on the code, ever! Niclas Ahden (Nov 01 2026 at 22:39):Issue: https://github.com/roc-lang/roc/issues/12784
Richard Feldman (Nov 01 2026 at 23:03):@notramo this would happen from just viewing the code even if you're not editing it, that's the concern
Richard Feldman (Nov 01 2026 at 23:03):so like you clone a repo just to look at the code and lsp starts doing this stuff
notramo (Nov 01 2026 at 23:04):Users rarely clone a potentially dangerous repo locally just to look at potentially dangerous code in the editor.
notramo (Nov 01 2026 at 23:05):In most cases they also run code that they downloaded.
notramo (Nov 01 2026 at 23:09):If I would clone an untrusted Roc repo, I would probably never run Helix, and instead use a pager to look at the code. Or not even clone it, but inspect it in the web UI of the Git hosting platform.
notramo (Nov 01 2026 at 23:10):The problem is that this LSP config gives users a false sense of security.
notramo (Nov 01 2026 at 23:10):It's the wrong boundary to use for security.
notramo (Nov 01 2026 at 23:11):If a repo is potentially dangerous, it's a whole other problem, users should probably not even clone it!
Luke Boswell (Nov 01 2026 at 23:13):I think the origin of the motivating issue came from a review of CVE's from other projects ... so it wasn't a hypothetical issue but something from another project.
notramo (Nov 01 2026 at 23:15):Yes, but if an actual CVE were found, I would recommend:
Luke Boswell (Nov 01 2026 at 23:16):It was CVE-2026-34060 I think
Luke Boswell (Nov 01 2026 at 23:17):Issue #11902 (https://github.com/roc-lang/roc/issues/11902) came from reviewing CVE-2026-34060, a Ruby LSP code-injection vulnerability (https://github.com/Shopify/ruby-lsp/security/advisories/GHSA-c4r5-fxqw-vh93). Ruby LSP inserted a workspace-controlled setting into a generated Gemfile, allowing a malicious project to execute code when opened in an editor.
The review identified a related trust concern in Roc: opening a file triggered dependency downloads and native compile-time evaluation without an explicit workspace-trust opt-in.
Roc did not share Ruby LSP’s injection defect. The review classified the concern as “weakness possible”, since escaping Roc’s effect-free compile-time evaluation would require an additional compiler or runtime bug.
Luke Boswell (Nov 01 2026 at 23:17):^^ a quick summary made by Codex
notramo (Nov 01 2026 at 23:18):Yes, but the practicality of it is nearly zero.
notramo (Nov 01 2026 at 23:20):Not to mention the UX aspect of warning fatigue. Users get used to the dialog and their muscle memory gets trained to grant the trust.
notramo (Nov 01 2026 at 23:22):It's a terrible security boundary, and nobody should rely on it.
roc check or roc run trusted packages, or grant the trust anyways, to get "goto definition" or type info. Luke Boswell (Nov 01 2026 at 23:35):We can document that CTFE must be effect-free to control for any malicious code limited to those harmless things. Then if we find a compiler bug in future that can be exploited we have a concrete vulnerability to report and address.
notramo (Nov 01 2026 at 23:37):CTFE must be effect-free for many other reasons too.
notramo (Nov 01 2026 at 23:37):Nobody wants code that behaves differently based on which machine it was compiled on.
Luke Boswell (Nov 01 2026 at 23:38):I agree that running arbitrary code from an untrusted source is just asking for trouble and there are few ways to control the risks from that -- even with Roc's platform abstraction and purity.
notramo (Nov 01 2026 at 23:38):Also, don't forget that if there's a hidden and undiscovered exploit in code that is trusted by the users, this measure is useless, because users are going to trust the repo via the dialog.
Luke Boswell (Nov 01 2026 at 23:40):It's not reasonable to expect there will never be any exploitable vulnerabilities in the compiler or cli. It's possible there may be something there that hasn't been discovered yet.
notramo (Nov 01 2026 at 23:41):I never said that we should not expect it to exist.
Luke Boswell (Nov 01 2026 at 23:41):I wrote that before your message, was just finishing a thought from above not responding to you there.
notramo (Nov 01 2026 at 23:42):I said that it's practically zero probability to this feature being the boundary that stops an exploit in a practical workflow.
Last updated: Nov 04 2026 at 18:54 UTC