Add workspace trust support by xe-nul · Pull Request #15177 · helix-editor/helix

xe-nul · 2026-01-23T16:59:55Z

Should fix #2697

This isn't quite ready to be pushed to main branch, but it does work (on my machine).

The biggest thing that it lacks is some kind of message that CWD is not in the list of trusted workspaces with an instruction on how to change that (I think that single prompt like "Current directory is not trusted; run ':workspace_trust' to enable all features' might be sufficient), but I couldn't figure out how to do that just yet.

Smaller flaws:

':workspace_trust' doesn't retroactively start LSP client in buffers and doesn't automatically reload the config (I don't know if we even want that, and LSP part might not be so simple AFAICT)
I think there should be a warning if user tries to add whole '/', or '/home/', or something equally bad to their trusted list
It doesn't disable tree-sitter (again, I am not sure if we want that, tree-sitter might be an attack vector, but I am not sure how proven that is. Perhaps, it should be a config option?)

xe-nul · 2026-01-23T21:26:33Z

Now it does show a warning when a new file is open. I don't really like that the message disappears on a first keypress since that makes it too easy to miss if one is not familiar with the feature, but I think it is not hostile to unsuspecting user any more.

the-mikedavis · 2026-01-23T21:52:53Z

Also see #14668. I haven't found the time lately but the Select component can be cleanly applied to master and provide LSP window/showMessageRequest in addition to this use-case

xe-nul · 2026-01-23T23:03:12Z

Yeah, Select feels much better, I'll work on it

xe-nul · 2026-01-23T23:51:06Z

I thought about it a bit, and I think Select approach is really good for discoverability of this feature: you can't miss it (we can safely add it to master/next release and people will not be surprised that their LSP doesn't work), and my current approach just doesn't get in the way (Select isn't that much obtrusive, but still it can be a bit unwieldy to click one more key when you open something like a config file to fix something quickly).

The way I see it, the default should be Select pop-up, and my current approach should be behind a config option, I'll try to do just that

xe-nul · 2026-01-24T13:27:23Z

Sorry about big messy PR, but I think it does what it needs to now.

Now, by default, it will prompt the user with Select UI element from @the-mikedavis's branch, I added this element with a separate commit, hope that will make it easier to review.

There is a config option editor.trust-selector that accepts two options: select (the default one) and simple. Simple is basically my initial implementation, for the case where user doesn't want to be explicitly promted about workspace trust every time they open a file in a directory for the first time.

Notes:

my implementation keeps it's files (trusted_workspaces and untrusted_workspaces) in XDG data directory, not in state directory, because state directory is only present with XDG strategy in etcetera lib, and on Windows strategy.state_dir() will (I didn't really test it, but I think it will) return None, so I think it's best to leave these files in data_dir for now ('~/.local/share/helix' on *nix)
LSP doesn't automatically start and config isn't automatically reloaded after trusting the workspace with either :workspace_trust or Select menu
it's kinda hacky and rough in some places

But I think I am mostly happy with it now, so I'll wait for some input.

Also see #14668. I haven't found the time lately but the Select component can be cleanly applied to master and provide LSP window/showMessageRequest in addition to this use-case

With Select in place, I think I can try to port this LSP message impl from that branch, but I think I better do it in a separate PR?

xe-nul · 2026-01-24T16:52:01Z

I've added an editor.trust-selector = "always-trust-lsp" option. It does what it says it does, but it would be great to add an option to restore old behavior: always trust everything. That would be kinda annoying to do with config.toml and languages.toml, so I decided not to do that right now

xe-nul · 2026-01-24T20:00:00Z

Alright, now both :workspace_trust and 'Always trust' option in Select menu do start LSP servers.

I have also added docs.

I think this thing is really ready to review now

m4rch3n1ng · 2026-01-24T20:23:41Z

        },
    },
+    TypableCommand {
+        name: "workspace_trust",


- name: "workspace_trust", + name: "workspace-trust",

typable commands in helix are kebab-case by convention and not snake_case.

Thanks, I think it is fixed everywhere now

the-mikedavis · 2026-01-25T17:45:50Z

I finally applied the Select component to master so this PR can be rebased on those changes now, 76c23b3. It's nearly the same as it was in my branch but I added some horizontal padding to the message

xe-nul · 2026-01-25T18:32:40Z

Just FYI, but I see a warning when building current master with nix build github:helix-editor/helix:

helix-term> warning: non-local `impl` definition, `impl` blocks should be written at the same level as their item
helix-term>     --> helix-term/src/application.rs:1121:25
helix-term>      |
helix-term> 759  |       ) {
helix-term>      |  _______-
helix-term> 760  | |         use helix_lsp::{Call, MethodCall, Notification};
helix-term> 761  | |
helix-term> 762  | |         macro_rules! language_server {
helix-term> ...    |
helix-term> 1121 | |                         impl ui::menu::Item for lsp::MessageActionItem {
helix-term>      | |                         ^^^^^--------------^^^^^----------------------
helix-term>      | |                              |                  |
helix-term>      | |                              |                  `MessageActionItem` is not local
helix-term>      | |                              `Item` is not local
helix-term> ...    |
helix-term> 1174 | |     }
helix-term>      | |_____- move the `impl` block outside of this async fn `<unnameable>` and up 2 bodies
helix-term>      |
helix-term>      = note: an `impl` is never scoped, even when it is nested inside an item, as it may impact type checking outside of that item, which can be the case if neither the trait or the self type are at the same nesting level as the `impl`
helix-term>      = note: `#[warn(non_local_definitions)]` on by default
helix-term> warning: hiding a lifetime that's elided elsewhere is confusing
helix-term>     --> helix-term/src/application.rs:1123:39
helix-term>      |
helix-term> 1123 | ...                   fn format(&self, _data: &Self::Data) -> tui::widgets::Row {
helix-term>      |                                 ^^^^^                         ----------------- the same lifetime is hidden here
helix-term>      |                                 |
helix-term>      |                                 the lifetime is elided here
helix-term>      |
helix-term>      = help: the same lifetime is referred to in inconsistent ways, making the signature confusing
helix-term>      = note: `#[warn(mismatched_lifetime_syntaxes)]` on by default
helix-term> help: use `'_` for type paths
helix-term>      |
helix-term> 1123 |                             fn format(&self, _data: &Self::Data) -> tui::widgets::Row<'_> {
helix-term>      |                                                                                      ++++
helix-term> warning: `helix-term` (lib) generated 2 warnings
helix-term>     Finished `release` profile [optimized] target(s) in 2m 37s

I only see this warning when building with nix, cargo clippy for example doesn't produce this warning. I already saw something similar earlier, is it possible that nix build and nix develop are using different toolchain versions?

xe-nul · 2026-01-25T18:50:19Z

All right, I rebased it on top of master and fixed a bug in the implementation that I've just found. Should be ready for review again

the-mikedavis · 2026-01-25T18:56:52Z

Ah yeah, when building the package we use the latest stable if I remember correctly, so it shows warnings which aren't emitted by the MSRV. And the devShell is using the MSRV. I'll push some fixes for more recent rustc / clippy

archseer · 2026-01-26T02:05:02Z

+        match fs::read_to_string(workspace_trust_file()) {
+            Ok(workspace_trust_file) => {
+                for line in workspace_trust_file.split('\n') {
+                    if !line.is_empty() {
+                        let path = PathBuf::from(line);
+                        trusted.insert(path);
+                    }
+                }
+            }
+            Err(e) => log::error!("workspace file couldn't be read: {:?}", e),
+        };


This pattern seems repeated multiple times

I think it would be more efficient to read the file in a streaming way, returning a line iterator we can scan through

Now load() is used only when there is a need to write changes to trust-related files. For checking the trust there are quick_query_workspace() and quick_query_workspace_with_explicit_untrust() functions now, they do basically what you've described.

Fixed repeated pattern now too

quick_query_workspace() and quick_query_workspace_with_explicit_untrust() functions now, they do basically what you've described.

Well, sort of. They both use read_to_string which blocks until the entire file has been loaded into memory. If the files were line-buffered (e.g. BufRead::lines) then the iterator can yield the lines immediately as they arrive from storage.

This is why I'm concerned about perf

#15590 should address the comments above

archseer · 2026-01-26T02:07:59Z

+        }
+    }
+
+    fn write_untrust_to_file(&self) {


I think there should be just one trust file, and untrust only removes entries. Users should either opt to trust all workspaces, or selectively trust. Blacklisting specific entries is too error prone because if you forget you're vulnerable. Same with opening the workspace then calling :untrust on it: by that point it's already too late since the config got executed

I went with only one trust file initially, and I added second blacklist file after I copied Select UI approach from Mike's branch since that has Not now and Never options, and for Never to work we need to parse an additional file.

When trust-selector = "simple" config option is set, it doesn't check that second file since it doesn't really need to ("simple" is basically implementation of your ideas from #2697 (comment)).

:workspace-untrust is more of a convenience feature that you would only use because it is easier than modifying trust file by hand. Every workspace is still not trusted until user says it is.

If we want to remove second file, we need to remove Never option from the default trust selector approach, and I am not sure yet that we want that

I think there should just be two modes: insecure=true that trusts everything and the default where each workspace has to be explicitly appproved. This should match VSCode behaviour

Yeah, you're right, I just changed it.

I wanted to have a middle ground between trusting everything and having to click through a pop-up, but Select is really good, I lived for a week with it and it doesn't get in the way.

xe-nul · 2026-01-29T13:03:17Z

I renamed untrusted_workspaces file to excluded_workspaces, hope this will make it more clear what that file does.

Tested - the path is the same on Linux and macOS

oliverpool · 2026-03-26T17:49:44Z

@@ -0,0 +1,23 @@
+# Workspace trust
+
+Helix has a number of potentially dangerous features, namely LSP and ability to use local to workspace configurations. Those features can lead to unexpected code execution. To protect against code execution in dangerous contexts, Helix has a workspace trust protection, which will prevent these potentially dangerous features from running automatically.


Thank you so much for this PR!

I am not sure to understand the doc:

Will untrusted workspaces not have any LSP enabled (even if globally set) and not local config (which can contain LSP and language settings)?

Or are the global LSP always enabled?

I would suggest at the end:

Helix has a workspace trust protection, which will disable the following features:

loading config the the workspace’s .helix folder (language matching, LSP…)

running the globally configured LSPs

(Btw “ability to use local to workspace configurations” reads convoluted)

Yeah, nothing can load local configs or start an LSP server/client until workspace is trusted. I will try to do something about the docs

Does that look better to you?

Yes, I find it clearer. Thanks!

Regarding “trust”, the child folders of trusted workspaces are also trusted, right?

So if I trust ~/work, every (sub-)subfolder in it will be automatically trusted, right?

Probably not in the way you expect it to work.

This is the function that selects the workspace:

helix/helix-loader/src/lib.rs

Line 265 in 253e619

pub fn find_workspace() -> (PathBuf, bool) {

If your ~/work is a git repository, then yeah. If not, then you'll have to trust each repository in it when needed.

Originally, I did exactly what you described: walking directory tree up and looking if any parent is trusted, but that is not only slower, but a giant footgun too: you can open a file in your /home, allow trust there, forget about it, and then basically everything you open will be trusted. IMO better design is to make prompt about trust as unobtrusive as possible, which I hope this PR achieves

Ok, thanks for the detailed explanation!

I appreciate the vscode prompt, which offers a nice middle ground I think: the ability to trust one parent level (ie all direct children of ~/work could be marked as trusted, but sub-children must be trusted explicitly).

Note that I am already satisfied with this feature, and just want to give some (hopefully constructive) feedback ❤️

@archseer

* Workspace trust: init * Apply suggestion from @archseer * Apply suggestion from @the-mikedavis Tested - the path is the same on Linux and macOS * Avoid logging when workspace trust files can't be read from NotFound --------- Co-authored-by: Blaž Hrastnik <blaz@mxxn.io> Co-authored-by: Michael Davis <mcarsondavis@gmail.com>

HigherOrderLogic · 2026-04-03T13:40:18Z

I am making a PR to add "only once" trust option, does it makes sense? Just want to gauge the opinion before actually opening a PR.

the-mikedavis · 2026-04-04T16:00:49Z

I think it would make sense to have an option that trusts the current config. We'd take a cryptographic hash of the config and store it in the trust file(s). That would prevent future git pulls from surprising you with config changes and let you trust whatever is there that you have already vetted.

In the wild I know https://github.com/direnv/direnv works like this.

@archseer

* Workspace trust: init * Apply suggestion from @archseer * Apply suggestion from @the-mikedavis Tested - the path is the same on Linux and macOS * Avoid logging when workspace trust files can't be read from NotFound --------- Co-authored-by: Blaž Hrastnik <blaz@mxxn.io> Co-authored-by: Michael Davis <mcarsondavis@gmail.com>

xe-nul marked this pull request as ready for review January 23, 2026 21:27

xe-nul marked this pull request as draft January 23, 2026 23:03

xe-nul force-pushed the workspace_trust branch from 078a835 to e2a8f8f Compare January 24, 2026 12:54

xe-nul marked this pull request as ready for review January 24, 2026 13:27

This comment was marked as resolved.

Sign in to view

xe-nul force-pushed the workspace_trust branch 2 times, most recently from b937531 to 5d85500 Compare January 24, 2026 16:38

xe-nul changed the title ~~WIP: Add rudimentary workspace trust support~~ Addworkspace trust support Jan 24, 2026

xe-nul changed the title ~~Addworkspace trust support~~ Add workspace trust support Jan 24, 2026

xe-nul force-pushed the workspace_trust branch 3 times, most recently from 0869ce5 to 682a197 Compare January 24, 2026 19:15

m4rch3n1ng reviewed Jan 24, 2026

View reviewed changes

xe-nul force-pushed the workspace_trust branch from 1f6a4c8 to 7d6a301 Compare January 24, 2026 20:42

xe-nul force-pushed the workspace_trust branch from 7d6a301 to 93a6bfa Compare January 25, 2026 18:09

xe-nul force-pushed the workspace_trust branch from 93a6bfa to 19c41bc Compare January 25, 2026 18:42

archseer reviewed Jan 26, 2026

View reviewed changes

xe-nul force-pushed the workspace_trust branch 2 times, most recently from b0ccafc to ffb8195 Compare January 26, 2026 14:25

xe-nul force-pushed the workspace_trust branch 3 times, most recently from c004ccb to b84fe28 Compare February 1, 2026 16:05

xe-nul force-pushed the workspace_trust branch 2 times, most recently from 1bd9d84 to 07e4a44 Compare March 11, 2026 16:47

archseer requested a review from the-mikedavis March 17, 2026 05:32

xe-nul force-pushed the workspace_trust branch 2 times, most recently from 52af224 to 20849a8 Compare March 25, 2026 10:34

Workspace trust: init

0151bc5

xe-nul force-pushed the workspace_trust branch from 20849a8 to 0151bc5 Compare March 25, 2026 14:34

archseer reviewed Mar 26, 2026

View reviewed changes

Comment thread book/src/workspace-trust.md Outdated

Apply suggestion from @archseer

7415dcf

the-mikedavis reviewed Mar 26, 2026

View reviewed changes

Comment thread book/src/workspace-trust.md Outdated

Apply suggestion from @the-mikedavis

968c0fa

Tested - the path is the same on Linux and macOS

the-mikedavis previously approved these changes Mar 26, 2026

View reviewed changes

archseer previously approved these changes Mar 26, 2026

View reviewed changes

Avoid logging when workspace trust files can't be read from NotFound

4b0cd82

the-mikedavis dismissed stale reviews from archseer and themself via 4b0cd82 March 26, 2026 16:32

archseer approved these changes Mar 26, 2026

View reviewed changes

archseer merged commit 0475fdd into helix-editor:master Mar 26, 2026
7 checks passed

oliverpool reviewed Mar 26, 2026

View reviewed changes

maribu mentioned this pull request Mar 31, 2026

feat(helix-loader): support globbing for trust files #15556

Closed

Rudxain mentioned this pull request Apr 4, 2026

fix & refactor: workspace-trust #15582

Closed

RickdeJager mentioned this pull request Apr 6, 2026

[security] Trusted workspace bypass via .git/config allows arbitrary command execution #15594

Open

		@@ -0,0 +1,23 @@
		# Workspace trust

		Helix has a number of potentially dangerous features, namely LSP and ability to use local to workspace configurations. Those features can lead to unexpected code execution. To protect against code execution in dangerous contexts, Helix has a workspace trust protection, which will prevent these potentially dangerous features from running automatically.

Uh oh!

Conversation

xe-nul commented Jan 23, 2026

Uh oh!

xe-nul commented Jan 23, 2026

Uh oh!

the-mikedavis commented Jan 23, 2026

Uh oh!

xe-nul commented Jan 23, 2026

Uh oh!

xe-nul commented Jan 23, 2026

Uh oh!

xe-nul commented Jan 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as resolved.

xe-nul commented Jan 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xe-nul commented Jan 24, 2026

Uh oh!

m4rch3n1ng Jan 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

the-mikedavis commented Jan 25, 2026

Uh oh!

xe-nul commented Jan 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xe-nul commented Jan 25, 2026

Uh oh!

the-mikedavis commented Jan 25, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xe-nul Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Rudxain Apr 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xe-nul Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xe-nul commented Jan 29, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

xe-nul commented Jan 24, 2026 •

edited

Loading

xe-nul commented Jan 24, 2026 •

edited

Loading

m4rch3n1ng Jan 24, 2026 •

edited

Loading

xe-nul commented Jan 25, 2026 •

edited

Loading

xe-nul Jan 26, 2026 •

edited

Loading

Rudxain Apr 4, 2026 •

edited

Loading

xe-nul Jan 26, 2026 •

edited

Loading

the-mikedavis commented Apr 4, 2026 •

edited

Loading