Fix `OpenFiles` action not respecting `use_system_path_prompts` setting by austincummings · Pull Request #47027 · zed-industries/zed

austincummings · 2026-01-16T22:05:39Z

The OpenFiles action was always using the system file picker dialog, ignoring the use_system_path_prompts setting. This adds a workspace-level handler that calls prompt_for_open_path, which respects the setting, instead of falling through to the global handler.

Closes #46386

Release Notes:

Fixed "workspace: open files" not respecting "use_system_path_prompts" setting

SomeoneToIgnore

Great idea, but why keep the other action handler at all, with this approach?

Also, it seems prompt_and_open_paths is used on CloseWindow — this is also a wrong place to keep the native prompt.

Maybe, the answer is to alter fn prompt_and_open_paths entirely (or remove it and use whatever one works instead)?

austincummings · 2026-01-23T16:52:50Z

Great idea, but why keep the other action handler at all, with this approach?

True, it seems like that global handler isn't ever called with this approach, at least on Linux, I'm not sure about other OS's or if OS would affect that. The same is true for the Open handler in workspace.rs.

Also, it seems prompt_and_open_paths is used on CloseWindow — this is also a wrong place to keep the native prompt.

Hm, I'm not seeing where this is. I'm only seeing this:

zed/crates/workspace/src/workspace.rs

Line 621 in 9ef825d

cx.on_action(|_: &CloseWindow, cx| Workspace::close_global(cx))

Maybe, the answer is to alter fn prompt_and_open_paths entirely (or remove it and use whatever one works instead)?

Done. So these two handlers below were removed, since I didn't see how they could be hit since they both now have workspace level handlers and they ignored the users settings. Then just cleaned up the unused app_state from the workspace::init and the call-sites.

zed/crates/workspace/src/workspace.rs

Lines 623 to 657 in 9ef825d

    
           .on_action({ 
        
               let app_state = Arc::downgrade(&app_state); 
        
               move |_: &Open, cx: &mut App| { 
        
                   if let Some(app_state) = app_state.upgrade() { 
        
                       prompt_and_open_paths( 
        
                           app_state, 
        
                           PathPromptOptions { 
        
                               files: true, 
        
                               directories: true, 
        
                               multiple: true, 
        
                               prompt: None, 
        
                           }, 
        
                           cx, 
        
                       ); 
        
                   } 
        
               } 
        
           }) 
        
           .on_action({ 
        
               let app_state = Arc::downgrade(&app_state); 
        
               move |_: &OpenFiles, cx: &mut App| { 
        
                   let directories = cx.can_select_mixed_files_and_dirs(); 
        
                   if let Some(app_state) = app_state.upgrade() { 
        
                       prompt_and_open_paths( 
        
                           app_state, 
        
                           PathPromptOptions { 
        
                               files: true, 
        
                               directories, 
        
                               multiple: true, 
        
                               prompt: None, 
        
                           }, 
        
                           cx, 
        
                       ); 
        
                   } 
        
               } 
        
           });

Let me know if I can do anything more on this, thanks!

SomeoneToIgnore

Hm, I'm not seeing where this is.

Right, that part is either gone or I was wrong, sorry — either way it's nothing to worry about now.

Really sorry for confusing you here: the global handler is actually very important for macOs as there, the app can be alive without any UI present onscreen, hence certain commands like "open a file" are expected to work there.

With .register_action only we cannot achieve that, as this way the listener is registered on a particular workspace which is a Window at the same time in Zed, which won't exist at the moment described above.

So, we need a global listener, after all — for that, it should be simple to move the register_action code there.
That presumably now will invoke the code with the modal, right?

The next question is whether that's enough — you mention that the global is not called on Linux at all and that makes sense as on that OS the app exists after its last window is closed.
But, that global handler was shadowed by the local one before — hence, when we remove the local and leave the global only, it presumably should start running?

Otherwise, looks good, we're seem to be close.

crates/workspace/src/workspace.rs

austincummings · 2026-02-12T21:12:48Z

Gotcha, I think in that case the original approach of having two handlers should work best right? The register_action handler works when there is a window open - which is always in the case of Linux. While the on_action handler handles the macOS case of no window being open and falling back to the system file opener. This matches how workspace::Open works as well I believe?

Thank you for your guidance!

SomeoneToIgnore · 2026-02-12T21:17:40Z

Well, I wish you can think on something yourself instead of forcing me to — this is the whole point of contributions I have thought 🙂

My words are not what you have stated: I think that it's enough to have a global handler only.
But I am only guessing, I hope someone can verify the combination(s) and find the minimal one...

The OpenFiles action was always using the system file picker dialog, ignoring the use_system_path_prompts setting. This adds a workspace-level handler that calls prompt_for_open_path, which respects the setting, instead of falling through to the global handler.

austincummings · 2026-02-13T17:49:04Z

After playing around with implementing the single global handler - I do believe the two handler approach to be the correct one and most consistent with how the other (workspace::Open) handler works. It makes sense to me to have the global handler dedicated to when there is no window open, and so it will always use the system picker. And keep the workspace level handler so it can show the built-in picker in that window.

The two global handlers will never be called on Linux or Windows though AFAIK, so it's essentially macOS only (at least until Zed can run in the background on Linux or Windows). I messed around with wrapping that in #[cfg(target_os = "macos")] but it was a bit ugly, and unfortunately I don't have a Mac to test it with.

I rebased and dropped the last few commits and am sticking with just the initial commit I made for this.

…stem-prompts-settings

SomeoneToIgnore

I have deduplicated the logic as asked in #47027 (review) and tested on mac (both with and without the window) and Linux — both cases seem to work.

Thank you for spotting, and congrats with the first contribution.

cla-bot bot added the cla-signed The user has signed the Contributor License Agreement label Jan 16, 2026

zed-community-bot bot added the first contribution the author's first pull request to Zed. NOTE: the label application is automated via github actions label Jan 16, 2026

MrSubidubi changed the title ~~Fix OpenFiles action not respecting use_system_path_prompts setting~~ Fix OpenFiles action not respecting use_system_path_prompts setting Jan 17, 2026

SomeoneToIgnore requested changes Jan 22, 2026

View reviewed changes

SomeoneToIgnore self-assigned this Jan 22, 2026

austincummings force-pushed the fix-open-files-use-system-prompts-settings branch from 02963f1 to 7c0b777 Compare January 23, 2026 16:42

austincummings force-pushed the fix-open-files-use-system-prompts-settings branch 2 times, most recently from eba094d to f669ee3 Compare January 27, 2026 13:31

austincummings force-pushed the fix-open-files-use-system-prompts-settings branch 2 times, most recently from bfd11fb to 5b47d50 Compare February 10, 2026 18:35

lingyaochu mentioned this pull request Feb 11, 2026

use_system_path_prompts to false still use the system one #48882

Closed

SomeoneToIgnore reviewed Feb 12, 2026

View reviewed changes

crates/workspace/src/workspace.rs Show resolved Hide resolved

austincummings force-pushed the fix-open-files-use-system-prompts-settings branch from 5b47d50 to e49e43b Compare February 13, 2026 17:49

Actually deduplicate the code

b95b32a

SomeoneToIgnore requested review from a team as code owners February 19, 2026 01:44

SomeoneToIgnore requested review from reflectronic and smitbarmase and removed request for a team, reflectronic and smitbarmase February 19, 2026 01:44

Merge remote-tracking branch 'origin/main' into fix-open-files-use-sy…

e2165b5

…stem-prompts-settings

SomeoneToIgnore approved these changes Feb 19, 2026

View reviewed changes

SomeoneToIgnore merged commit 157a02e into zed-industries:main Feb 19, 2026
27 checks passed

austincummings deleted the fix-open-files-use-system-prompts-settings branch February 25, 2026 18:08

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Fix `OpenFiles` action not respecting `use_system_path_prompts` setting#47027

Fix `OpenFiles` action not respecting `use_system_path_prompts` setting#47027
SomeoneToIgnore merged 3 commits intozed-industries:mainfrom
austincummings:fix-open-files-use-system-prompts-settings

austincummings commented Jan 16, 2026

Uh oh!

SomeoneToIgnore left a comment

Uh oh!

austincummings commented Jan 23, 2026

Uh oh!

SomeoneToIgnore left a comment

Uh oh!

Uh oh!

austincummings commented Feb 12, 2026

Uh oh!

SomeoneToIgnore commented Feb 12, 2026

Uh oh!

austincummings commented Feb 13, 2026

Uh oh!

SomeoneToIgnore left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

austincummings commented Jan 16, 2026

Uh oh!

SomeoneToIgnore left a comment

Choose a reason for hiding this comment

Uh oh!

austincummings commented Jan 23, 2026

Uh oh!

SomeoneToIgnore left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

austincummings commented Feb 12, 2026

Uh oh!

SomeoneToIgnore commented Feb 12, 2026

Uh oh!

austincummings commented Feb 13, 2026

Uh oh!

SomeoneToIgnore left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants