Reproduction steps
Summary
When I open several folders at once with Zed.exe <dir1> <dir2> <dir3>, the editor creates a single workspace that contains all three directories as project roots. The left Threads panel shows a single combined thread, and the project panel lists all roots expanded. If one root contains a long file list, switching to another root requires a lot of scrolling.
When I open the same folders by right-clicking each one in Windows Explorer and selecting Open with Zed, each folder appears as its own thread in the left Threads panel, and I can switch between them quickly. I would like the CLI to behave the same way.
Steps to Reproduce
- Create three sibling folders, for example:
test-folder-alphatest-folder-betatest-folder-gamma
- From PowerShell, run
Zed.exewith all three paths as arguments:This can also be reproduced with the attached scriptZed.exe "C:\Users\...\test-folder-alpha" "C:\Users\...\test-folder-beta" "C:\Users\...\test-folder-gamma"zed-open.ps1. - Compare with right-clicking each of the three folders individually and choosing Open with Zed.
Screenshots
- Desired behavior after right-clicking each folder:
right-open-multi-folders-threads.png - Actual behavior after running
Zed.exewith three folders:
ps-open-multi-folders.png - Single folder opened by right-click (for reference):
right-open-folder1.png - Parent folder opened by right-click (for reference):
right-open-top-folder.png
Additional Context
Zed.exe --help shows that it accepts a sequence of [PATHS_OR_URLS]..., but there does not appear to be a CLI flag (for example --new-window or --separate-threads) to force each path into its own window or thread. The only workaround right now is to invoke Zed.exe once per folder, which is inconvenient when opening many folders at once from a script.
Ideally, the CLI and the Windows context menu would have the same semantics: opening multiple folders should give the same result as opening each one separately, so the left Threads panel can be used to switch between them quickly.
Current vs. Expected behavior
Expected Behavior
Zed.exe with multiple directories should behave like right-clicking each folder individually: each directory should become a separate thread in the left Threads panel, and the project panel should show only the selected directory at a time.
Actual Behavior
Zed.exe with multiple directories opens a single window with a multi-root workspace. The left Threads panel shows one entry named after all three directories (test-folder-alpha, test-folder-beta, test-folder-gamma), and the project panel lists all three roots expanded. When one folder has a long file list, I have to scroll past it to reach the next folder.
Zed version and system specs
Environment
Zed: v1.26.2+stable.384.c4273271092b0287f7d181f616bd5171e0a2f70c (Zed)
Commit: c4273271092b0287f7d181f616bd5171e0a2f70c
OS: Windows 10.0.26200
Memory: 15.5 GiB
Architecture: x86_64Attach Zed log file
Zed.log
undefinedRelevant Zed settings
settings.json
undefinedRelevant Keymap
keymap.json
undefined(for AI issues) Model provider details
No response
If you are using WSL on Windows, what flavor of Linux are you using?
No response
Activity
2@LeiYangGH I confirmed the grouping on macOS 15.8.1 with Nightly 1.27.0+nightly.3484 (5e8998a2). One invocation with three directories opened one workspace containing all three roots. Adding -n did not split them into separate workspaces.
Commands and results
With three disposable directories:
zed -n /path/to/alpha /path/to/beta /path/to/gammaThis opened one new window with all three project roots and one combined sidebar entry.
As a control, I ran:
zed -n /path/to/alpha
zed -n /path/to/beta
zed -n /path/to/gammaThat opened three windows, each with one project root. This does not reproduce your desired separate project entries in the same window, and I haven’t tested Windows Explorer’s “Open with Zed” action.
The local open-request handler takes the full list of paths and passes it to one open_paths_with_positions call:
That explains the current behavior, but doesn’t establish that it’s the intended behavior. The CLI reference says “Open paths in a new workspace window”; it doesn’t explicitly explain how multiple directory arguments are grouped. I’m leaving the bug-versus-feature decision open. Dino’s (@/dinocosta) on triage this week, so I’m hoping he sees this and can confirm or deny my findings.