Honor cli_default_open_behavior for File menu ‘Open Folder’ / ‘Open Remote’ actions

[EgorKulikov]

Problem

"File → Open Folder…" and "File → Open Remote…" (and the recent-projects picker) always replace the current workspace. There is a settings key cli_default_open_behavior: "new_window" that solves this for the CLI (zed <path>), but the menu actions don't honor it — they dispatch their actions with create_new_window: false hard-coded.

Reference: crates/zed/src/zed/app_menus.rs constructs e.g. zed_actions::OpenRecent { create_new_window: false } and the "Open Folder" menu dispatches workspace::Open with the default value (also false).

The only user-side workaround is rebinding the keyboard shortcuts in keymap.json to pass { "create_new_window": true } — but the menu click itself remains untouchable from user config.

Proposal

Make the existing cli_default_open_behavior setting (or a parallel menu_default_open_behavior) apply to:

• File → Open Folder…
• File → Open Remote…
• File → Open Recent (picker + menu submenu)
• macOS Dock right-click recent-projects (closely related to Zed should open projects in a new window #55737)

So a user who has already opted into "open in new window" via settings gets consistent behavior whether they invoke the action via menu, CLI, or keyboard shortcut.

Related

• Opening a new directory/project does not open a new window #53528 — same root cause for the CLI/worktree path (already reproducible)
• Open recent Project reopens a new window instead of reusing an already opened window #54657 — Open Recent opens new window inconsistency
• Zed should open projects in a new window #55737 — closed sister issue for the macOS Dock menu