Skip to content

workspace: Fix cross-host window reuse - #62561

Open
hamishc wants to merge 1 commit into
zed-industries:mainfrom
hamishc:hamishc-remote-folder-redirect-bug
Open

workspace: Fix cross-host window reuse#62561
hamishc wants to merge 1 commit into
zed-industries:mainfrom
hamishc:hamishc-remote-folder-redirect-bug

Conversation

@hamishc

@hamishc hamishc commented Aug 13, 2026

Copy link
Copy Markdown

Objective

Opening a remote folder on one host can silently activate an already-open window connected to a different host that has an identically-named path, instead of connecting.

Repro:

  1. Open /foo/bar on ssh host A, then open a project on host B in the same window (host A's workspace stays retained in the background).
  2. From a new window, use Open Recent to open /foo/bar on host B.
  3. The existing window is activated still showing host A's project - no connection attempt, no error.

Cause: find_existing_workspace filters candidate windows by host, but then path-scores every workspace held in a qualifying window without checking each workspace's own location, so a request for host B can match host A's workspace by path alone. The window fallbacks in open_paths and the --wait branch had the same flaw - they used the window's displayed workspace unchecked, so zed could resolve a local path on a remote host.

Solution

  • Match each held workspace against the requested location before path scoring in find_existing_workspace.
  • Make the open_paths and --wait window fallbacks target a workspace at the requested location (preferring the displayed one) instead of the displayed one unconditionally.
  • Skip non-local projects in the CLI's paths_in_existing_workspace scan.
  • Log when an existing window is reused instead of connecting, to make future reports diagnosable.

Testing

  • New regression test (test_find_existing_workspace_requires_matching_location) covering the scoring loop and the --wait fallback in a mixed-location window; verified it fails without the fix.
  • cargo test -p workspace -p recent_projects, cargo check -p zed, and ./script/clippy all pass.
  • Tested on Linux only; behavior is platform-independent (window/workspace matching logic).
  • Reviewers can repro with two SSH hosts sharing a folder path using the steps above.

Self-Review Checklist:

  • I've reviewed my own diff for quality, security, and reliability
  • Unsafe blocks (if any) have justifying comments
  • The content adheres to Zed's UI standards (UX/UI and icon guidelines)
  • Tests cover the new/changed behavior
  • Performance impact has been considered and is acceptable

Release Notes:

  • Fixed opening a remote folder activating a window connected to a different host with the same folder structure, instead of connecting.

@cla-bot cla-bot Bot added the cla-signed The user has signed the Contributor License Agreement label Aug 13, 2026
@zed-community-bot 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 Aug 13, 2026
@dinocosta dinocosta added area:workspace Feedback for workspace management, layout, interactions, etc platform:remote Remote development, SSH and zed-remote-server labels Aug 14, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:workspace Feedback for workspace management, layout, interactions, etc cla-signed The user has signed the Contributor License Agreement first contribution the author's first pull request to Zed. NOTE: the label application is automated via github actions platform:remote Remote development, SSH and zed-remote-server

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants