Closes https://github.com/zed-industries/zed/issues/56219
Contains 3 commist:
*
https://github.com/zed-industries/zed/pull/56380/changes/a8d55273d6cddb39868a1fd669c5069a1133a373
shows better errors when CLI or main binary fail early: no backtraces,
better error context, diff file paths shown
*
https://github.com/zed-industries/zed/pull/56380/changes/d389f7ee239dcf9bfa2bfe91729d96d2c1931663
stops opening Zed if cli `--diff` path argument(s) does not exist, also
switches over async fs API on the Zed side.
This is a behavior change, as before Zed tried to open or connect to an
instance — can be reverted if needed.
With `Path::exists` check CLI will do now:
<img width="669" height="55" alt="now"
src="https://github.com/user-attachments/assets/bdfbef2f-1b28-443d-8a01-0ff73ec0bba1"
/>
If I remove that bit, Zed will now open in the same cwd where the CLI is
invoked in:
<img width="1724" height="639" alt="reverted"
src="https://github.com/user-attachments/assets/69cd171b-aca3-445b-8647-5786f3360ce4"
/>
*
https://github.com/zed-industries/zed/pull/56380/changes/49787b7366336711b5bfc11ba3661f3ba70ce8ca
fixes an underlying bug leading to memory leak.
If on current `main`, I apply
```diff
diff --git a/crates/zed/src/zed/open_listener.rs b/crates/zed/src/zed/open_listener.rs
index 18ea7c0869..5db22521f2 100644
--- a/crates/zed/src/zed/open_listener.rs
+++ b/crates/zed/src/zed/open_listener.rs
@@ -791,6 +791,7 @@ async fn open_local_workspace(
// working directory so the workspace opens with the right context.
if !user_provided_paths && !diff_paths.is_empty() {
if let Ok(cwd) = std::env::current_dir() {
+ log::error!("@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ {cwd:?}");
workspace_paths.push(cwd.to_string_lossy().into_owned());
}
}
```
I see the following logs:
```
2026-05-11T09:52:35+03:00 INFO [zed] ========== starting zed version 1.3.0+dev.7bdcb6172263dc05c0b59be76e09f3e89e23e4f1, sha 7bdcb61 ==========
2026-05-11T09:52:36+03:00 INFO [zed] Using git binary path: "/Applications/Zed Dev.app/Contents/MacOS/git"
2026-05-11T09:52:36+03:00 INFO [util] set environment variables from shell:/bin/zsh, path:/opt/homebrew/opt/llvm/bin:/Applications/Postgres.app/Contents/Versions/16/bin/:/Users/someonetoignore/Developer/PlaydateSDK/bin/:/Users/someonetoignore/.docker/bin/:/opt/homebrew/opt/armv7-unknown-linux-gnueabihf/bin/:/opt/homebrew/opt/rustup/bin/:/opt/homebrew/opt/go@1.19/bin/:/usr/local/opt/llvm/bin/:/Users/someonetoignore/.jetbrains/bin/:/Users/someonetoignore/.cargo/bin/:/usr/local/git/bin/:/opt/homebrew/Cellar/openjdk@21/21.0.6//bin/:/Users/someonetoignore/.local/state/fnm_multishells/75815_1778482356501/bin:/opt/homebrew/opt/ruby/bin:/opt/homebrew/lib/ruby/gems/4.0.0/bin:/opt/homebrew/bin:/opt/homebrew/sbin:/usr/local/bin:/System/Cryptexes/App/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/local/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/bin:/var/run/com.apple.security.cryptexd/codex.system/bootstrap/usr/appleinternal/bin:/opt/pkg/env/active/bin:/opt/pmk/env/global/bin:/opt/X11/bin:/Library/Apple/usr/bin:/Applications/Wireshark.app/Contents/MacOS:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/Users/someonetoignore/Library/pnpm:/opt/homebrew/opt/llvm/bin:/Applications/Postgres.app/Contents/Versions/16/bin/:/Users/someonetoignore/Developer/PlaydateSDK/bin/:/Users/someonetoignore/.docker/bin/:/opt/homebrew/opt/armv7-unknown-linux-gnueabihf/bin/:/opt/homebrew/opt/rustup/bin/:/opt/homebrew/opt/go@1.19/bin/:/usr/local/opt/llvm/bin/:/Users/someonetoignore/.jetbrains/bin/:/Users/someonetoignore/.cargo/bin/:/usr/local/git/bin/:/opt/homebrew/Cellar/openjdk@21/21.0.6//bin/:/Users/someonetoignore/.local/state/fnm_multishells/23413_1778480085615/bin:/opt/homebrew/opt/ruby/bin:/opt/homebrew/lib/ruby/gems/4.0.0/bin:/Users/someonetoignore/.cargo/bin:/Applications/iTerm.app/Contents/Resources/utilities:/Users/someonetoignore/.orbstack/bin:/Users/someonetoignore/.orbstack/bin
2026-05-11T09:52:36+03:00 INFO [zed::reliability] Debug assertions enabled, skipping hang monitoring
2026-05-11T09:52:36+03:00 WARN [zed::reliability] Minidump endpoint not set
2026-05-11T09:52:36+03:00 INFO [extension_host] extensions updated. loading 21, reloading 0, unloading 0
2026-05-11T09:52:37+03:00 ERROR [crates/zed/src/main.rs:1936] canonicalizing "crates/grammars/src": No such file or directory (os error 2)
2026-05-11T09:52:37+03:00 INFO [client] set status on client 0: Authenticating
2026-05-11T09:52:37+03:00 ERROR [zed::zed::open_listener] @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ "/"
2026-05-11T09:52:37+03:00 INFO [project::trusted_worktrees] Worktree "/" is not trusted
2026-05-11T09:52:37+03:00 ERROR [worktree] error reading target of symlink "/.VolumeIcon.icns": canonicalizing "/.VolumeIcon.icns": No such file or directory (os error 2)
2026-05-11T09:52:37+03:00 ERROR [worktree] error reading target of symlink "/Users/someonetoignore/.gitconfig.zed": canonicalizing "/Users/someonetoignore/.gitconfig.zed": No such file or directory (os error 2)
2026-05-11T09:52:37+03:00 INFO [workspace] Rendered first frame
2026-05-11T09:52:37+03:00 ERROR [worktree] error reading target of symlink "/usr/lib/libnetwork.dylib": canonicalizing "/usr/lib/libnetwork.dylib": No such file or directory (os error 2)
2026-05-11T09:52:37+03:00 WARN [fs] Failed to read symlink target metadata for path "/usr/sbin/weakpass_edit": Permission denied (os error 13)
2026-05-11T09:52:37+03:00 ERROR [worktree] error reading target of symlink "/usr/sbin/weakpass_edit": canonicalizing "/usr/sbin/weakpass_edit": Permission denied (os error 13)
2026-05-11T09:52:37+03:00 ERROR [worktree] error reading target of symlink "/usr/lib/libz.1.2.12.dylib": canonicalizing "/usr/lib/libz.1.2.12.dylib": No such file or directory (os error 2)
2026-05-11T09:52:37+03:00 ERROR [worktree] error reading target of symlink "/usr/lib/libpcre2-8.dylib": canonicalizing "/usr/lib/libpcre2-8.dylib": No such file or directory (os error 2)
2026-05-11T09:52:38+03:00 ERROR [worktree] error reading target of symlink "/var/run/docker.sock": canonicalizing "/var/run/docker.sock": No such file or directory (os error 2)
2026-05-11T09:52:38+03:00 ERROR [worktree] error processing "/var/db/DifferentialPrivacy": Operation not permitted (os error 1)
2026-05-11T09:52:38+03:00 ERROR [worktree] error reading target of symlink "/usr/lib/libipconfig.dylib": canonicalizing "/usr/lib/libipconfig.dylib": No such file or directory (os error 2)
2026-05-11T09:52:38+03:00 ERROR [worktree] error reading target of symlink "/private/var/run/docker.sock": canonicalizing "/private/var/run/docker.sock": No such file or directory (os error 2)
2026-05-11T09:52:38+03:00 ERROR [worktree] error processing "/private/var/db/DifferentialPrivacy": Operation not permitted (os error 1)
2026-05-11T09:52:38+03:00 ERROR [worktree] error processing "/Library/Caches/com.apple.amsengagementd.classicdatavault": Operation not permitted (os error 1)
2026-05-11T09:52:38+03:00 ERROR [worktree] error reading target of symlink "/usr/lib/libpcre2-posix.dylib": canonicalizing "/usr/lib/libpcre2-posix.dylib": No such file or directory (os error 2)
2026-05-11T09:52:38+03:00 ERROR [worktree] error processing "/Library/Caches/com.apple.aneuserd": Operation not permitted (os error 1)
2026-05-11T09:52:38+03:00 ERROR [worktree] error processing "/Library/Caches/com.apple.aned": Operation not permitted (os error 1)
```
According to
https://apple.stackexchange.com/questions/284754/what-is-the-default-working-directory-of-a-script-run-via-launchd
, the current directory of a running macOS app could be `/` if started
the way similar to how we do it via the CLI:
7bdcb61722/crates/cli/src/main.rs (L1306-L1329)
This means that every `std::env::current_dir()` is potentially dangerous
currently, as e.g. diff code tries to open this `/` as a worktree and
index it fully.
It seems that we're "ok" for now: the dangerous code is mostly in
extensions (there we set the cwd) and cli tools, and 2 places in
"development" Zed's code are left after this one is fixed.
There's one in `fs.rs` but that one is cfg-gated to Windows only hence
should not be an issue, at least the related one.
I'm not sure if this is the best way to fix the issue: setting `/` as an
app's current directory seems also wrong and maybe that invocation CLI
code could be altered somehow?
Maybe, `open_local_workspace` could be reworked somehow?
Seems that now we need a "shared directory" for both files we diff which
seems inevitable though, hence I've went on with passing the CLI's
current dir when opening items and that fixes the `/` issue along with
the OOM for now.
Release Notes:
- Fixed a memory leak with diffing non-existing files with Zed cli
## Summary
Fixes the missing Windows icon and version resource metadata for the
executable installed as `bin\zed.exe`.
On Windows, the bundling process builds `cli.exe` and installs it as
`bin\zed.exe`. The root `Zed.exe` already embeds the Zed Windows icon
and version metadata through `crates/zed/build.rs`, but the CLI
executable did not embed equivalent Windows resources.
As a result, Windows integrations that discover or display Zed through
`bin\zed.exe` may show a missing/default application icon.
This change adds Windows resource embedding to the `cli` crate and uses
the same release-channel icon selection as the main Zed executable.
Fixes#51154
## Testing
- Built the Windows CLI executable:
```powershell
cargo build --release --package cli --target x86_64-pc-windows-msvc
--locked --offline
```
- Verified `target\x86_64-pc-windows-msvc\release\cli.exe` contains:
- `FileDescription = Zed`
- `ProductName = Zed`
- Verified the executable displays the Zed icon in Windows Explorer.
- Confirmed the Windows bundling script installs `cli.exe` as
`bin\zed.exe`.
- Started a full Windows bundle build and confirmed it passed license
generation and progressed into executable builds. The local full bundle
build could not be completed because the machine is missing the VS
Spectre-mitigated C++ libraries.
## Release Notes
- N/A
## Notes
This change is limited to Windows executable resource metadata for the
CLI binary. It does not change Zed runtime behavior.
---------
Co-authored-by: John Tur <john-tur@outlook.com>
`zed --wait --diff <left> <right>` currently waits for the entire window
to close instead of just the diff itself, due to the combination of
- `zed --diff` adds the cwd to the paths to open (see #45131), and
- passing a directory to `zed --wait` blocks until the Zed window is
closed (see #44936), which doesn't distinguish between explicit paths
and the one `zed --diff` adds
Fixed by only running the `zed --wait <dir>` logic to block until the
window is closed in case the user actually passed any non-diff paths.
I've confirmed locally that it works, though I wasn't really sure how to
write a good test for this.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Release Notes:
- `zed --wait --diff <left> <right>` now blocks until the diff is
closed, and not until the entire window is closed.
This fixes a regression where `zed -n .` in a subdirectory of an
already-open
project would redirect to the parent window instead of creating a new
one.
The root cause was that commit 66d2cb20c9 ("Adjust `zed -n` behavior")
made
`-n` run the worktree matching loop with subdirectory matching enabled,
when
previously `-n` skipped matching entirely.
## Changes
### Bug fix
- **Restore `-n` to always create a new window.** No worktree matching,
no
exceptions. This matches the behavior from when `-n` was first
introduced.
### New `--classic` flag
- Adds a hidden `--classic` CLI flag that explicitly selects the
pre-sidebar
default behavior: new window for directories, reuse existing window for
files already in an open worktree.
- The `cli_default_open_behavior` setting now toggles between `-e` (add
to
sidebar) and `--classic` behavior. When set to `new_window`, the classic
logic is used instead of unconditionally opening a new window.
### Refactor CLI open options
Replaces the old grab-bag of `open_new_workspace: Option<bool>`,
`force_existing_window: bool`, `classic: bool`, and `reuse: bool` with:
- **`cli::CliOpenBehavior` enum** — a single enum on the IPC boundary
with
variants `Default`, `AlwaysNew`, `Add`, `ExistingWindow`, `Classic`, and
`Reuse`.
- **`workspace::WorkspaceMatching` enum** — describes how to match paths
against existing worktrees (`None`, `MatchExact`, `MatchSubdirectory`).
- **`workspace::OpenOptions`** — uses `WorkspaceMatching` plus a simple
`add_dirs_to_sidebar: bool` instead of overlapping boolean flags.
The translation from CLI enum to workspace options happens in
`open_listener.rs`, keeping both layers clean and independent.
Release Notes:
- N/A
Soft-deprecates the `-r`/`--reuse` CLI flag by hiding it from `--help`
output. The flag remains fully functional for backward compatibility,
but new users will discover `-e`/`--existing` instead.
The change is a single `hide = true` addition to the clap arg attribute.
Release Notes:
- N/A
On macOS, the CLI uses `LSOpenFromURLSpec` to deliver the `zed-cli://`
URL to the running Zed app. With `kLSLaunchDefaults`, Launch Services
activates (brings to foreground) the Zed app as a side effect of URL
delivery. This happens before the IPC handshake completes and before the
user can answer the terminal prompt asking whether to open in a new
window or existing workspace, forcing them to manually switch back to
the terminal.
## Fix
**CLI side** (`crates/cli/src/main.rs`): Add `kLSLaunchDontSwitch` to
the launch flags so macOS delivers the URL without activating the app.
**App side** (`crates/zed/src/zed/open_listener.rs`): Add
`cx.activate(true)` in `handle_cli_connection` after the prompt resolves
(or immediately for the URL-only path), so the app comes to the
foreground at the right time.
Linux and Windows are unaffected — they use Unix sockets and named pipes
respectively, which don't have activation side effects.
Release Notes:
- Fixed the Zed CLI activating the app window before the user answers
the open-behavior prompt in the terminal.
This PR adds the `cli_default_open_behavior` setting and a first-run TUI
prompt
that appears when `zed <path>` is invoked without flags while existing
windows are
open and the setting hasn't been configured yet.
## What it does
### Setting and prompt
- Adds a new `cli_default_open_behavior` workspace setting with two
values:
`existing_window` (default) and `new_window`.
- When the user runs `zed <path>` for the first time with existing Zed
windows
open, a `dialoguer::Select` prompt in the CLI asks them to choose their
preferred behavior. The choice is persisted to `settings.json`.
- The prompt is skipped when:
- An explicit flag (`-n`, `-e`, `-a`) is given
- No existing Zed windows are open
- The setting is already configured in `settings.json`
- The paths being opened are already contained in an existing workspace
### IPC transport abstraction
- Introduces a `CliResponseSink` trait in the `cli` crate that abstracts
`IpcSender<CliResponse>`, with an implementation for the real IPC
sender.
- Replaces `IpcSender<CliResponse>` with `Box<dyn CliResponseSink>` /
`&dyn CliResponseSink` across all signatures in `open_listener.rs`:
`OpenRequestKind::CliConnection`, `handle_cli_connection`,
`maybe_prompt_open_behavior`, `open_workspaces`, `open_local_workspace`.
- Extracts the inline CLI response loop from `main.rs` into a testable
`cli::run_cli_response_loop` function.
- Switches the request channel from bounded `mpsc::channel(16)` to
`mpsc::unbounded()`, eliminating `smol::block_on` in the bridge thread.
### End-to-end tests
Seven new tests exercise both the CLI-side response loop and the
Zed-side
handler connected through in-memory channels, using `allow_parking()` so
the
real `cli::run_cli_response_loop` runs on an OS thread while the GPUI
executor
drives the Zed handler:
- No flags, no windows → no prompt, opens new window
- No flags, existing windows, user picks "existing window" → prompt,
setting persisted
- No flags, existing windows, user picks "new window" → prompt, setting
persisted
- Setting already configured → no prompt
- Paths already in existing workspace → no prompt
- Explicit `-e` flag → no prompt
- Explicit `-n` flag → no prompt
Existing tests that previously used `ipc::channel()` now use a
`DiscardResponseSink`, removing OS-level IPC from all tests.
Release Notes:
- Added a first-run prompt when using `zed <path>` to choose between
opening
in an existing window or a new window. The choice is saved to settings
and
can be changed later via the `cli_default_open_behavior` setting.
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
## Before you mark this PR as ready for review, make sure that you have:
- [x] Added a solid test coverage and/or screenshots from doing manual
testing
- [x] Done a self-review taking into account security and performance
aspects
- [x] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
## Summary
Adds a `--dev-container` CLI flag that automatically triggers "Reopen in
Dev Container" when a `.devcontainer/` configuration is found in the
project directory.
```sh
zed --dev-container /path/to/project
```
## Motivation
This enables fully scripted dev container workflows — for example,
creating a git worktree and immediately opening it in a dev container
without any manual UI interaction:
```sh
git worktree add ../feature-branch
zed --dev-container ../feature-branch
```
The dev container modal fires automatically once the workspace finishes
initializing, so the environment is ready by the time you look at the
window. This is useful for automation scripts that prepare environments
and kick off agent runs for tasks like bug report triage.
Here's an [example
script](https://github.com/antont/todo-rs-ts/blob/main/scripts/devcontainer-new.sh)
that creates a worktree and opens it as a dev container in one step.
Related: #48682 requests a `devcontainer://` protocol for connecting to
already-running dev containers — a complementary but different use case.
This PR covers the "open project and trigger dev container setup" path.
## How it works
- The `--dev-container` flag flows through the CLI IPC protocol to the
workspace as an `open_in_dev_container` option.
- On the first worktree scan completion, if devcontainer configs are
detected, the dev container modal opens automatically.
- If no `.devcontainer/` config is found, the flag is cleared and a
warning is logged.
## Notable changes
- **`Workspace::worktree_scans_complete`** promoted from `#[cfg(test)]`
to production. It was only test-gated because it had no production
callers — it's a pure read-only future with no side effects.
- **`suggest_on_worktree_updated`** now takes `&mut Workspace` to read
and clear the CLI flag.
- Extracted **`open_dev_container_modal`** helper shared between the CLI
code path and the suggest notification.
## Test plan
- [x] `cargo test -p zed open_listener` — includes
`test_dev_container_flag_opens_modal` and
`test_dev_container_flag_cleared_without_config`
- [x] `cargo test -p recent_projects` — existing suggest tests still
pass
- [x] Manual: `cargo run -- --dev-container
/path/to/project-with-devcontainer` opens the modal
Release Notes:
- Added `--dev-container` CLI flag to automatically open a project in a
dev container when `.devcontainer/` configuration is present.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
This prevents child processes (e.g. shells) from inheriting it. This
generally isn't an issue, since zed is the only thing that cares about
it, but if you're trying to run zed *from* zed, you would first need to
unset it manually.
Release Notes:
- N/A
Otherwise, it's not easily possible to set *any* of these variables when
running Zed.
Release Notes:
- Added forwarding of `ZED_*` environment variables when using the
Flatpak
This branch:
1. teaches `--diff `command line option to to recurse into folders if
provided.
2. Adds a `MultiDiffView` that shows _all_ changed files in a single,
scrollable view.
This is necessary to provide a smooth user experience for `jj` and Zed
users who wish to use Zed as their jj difftool.
I'm not fully sure how this change interacts with
https://github.com/zed-industries/zed/pull/44936, or what plans y'all
have in mind.
Here's a screenshot of the resulting behavior:
<img width="1090" height="950" alt="Screenshot 2025-12-17 at 9 10 52 AM"
src="https://github.com/user-attachments/assets/8efd09b4-974f-4059-9f94-539c484c6d4a"
/>
I setup zed to handle jj diffs by adding the following to my jj config:
```toml
[aliases]
zdiff = ["diff", "--tool", "zed"]
[merge-tools.zed]
program = "/Users/dbarsky/Developer/zed/target/debug/cli"
# omit diff-invocation-mode to keep the default (JJ passes two dirs)
diff-args = [
"--zed", "/Users/dbarsky/Developer/zed/target/debug/zed",
"--wait",
"--new",
"--diff",
"$left",
"$right",
]
```
Release Notes:
- `--diff`, if provided with folders instead of files, will recurse into
those directories.
- Added a `MultiDiffView`, which will show all changed files within a
single, scrollable view.
**AI Disclosure**: Pretty much all of this code was written using Codex
with GPT-5.1-Codex. I edited by hand and tested this.
---------
Co-authored-by: Lukas Wirth <lukas@zed.dev>
Fixes#23347
Release Notes:
- Implemented the `zed --wait` flag so that it works when opening a
directory. The command will block until the window is closed.
Closes#40067
Release Notes:
- The `--user-data-dir` flag now works on Windows and Linux, as well as
macOS if you pass `--foreground`.
---------
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
This fixes running `zed <path>` inside nixos wsl instances. We're
copying the approach used elsewhere which is to try using `--exec`
first, and if that fails use an actual shell which should cover the
nixos case because it only puts binaries on your PATH inside the
`/etc/profile` script which is sourced on shell startup.
Release Notes:
- N/A
---------
Co-authored-by: John Tur <john-tur@outlook.com>
Changes are made to `parse_path_with_position`:
we try to get the canonical, existing parts of
a path, then append the non-existing parts.
Closes#4441
Release Notes:
- Added the possibility to open a non-existing path using `zed` CLI
```
zed path/to/non/existing/file.txt
```
Co-authored-by: Syed Sadiq Ali <sadiqonemail@gmail.com>
Thread stacks in rust by default have 2 megabytes of stack which for
sumtrees (or ropes in this case) can easily be exceeded depending on the
workload.
Release Notes:
- Fixed stack overflows when constructing large ropes
We only use it a handful of times and the default amount of threads
(logical cpu core number) its spawns is overkill for this. This also
gives the threads names oppose to being labeled `<unknown>`
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
it is was still in
[discussion](https://github.com/zed-industries/zed/discussions/37983)
Release Notes:
- Added: `--reuse` (`-r`) CLI flag to replace the workspace in an
existing window instead of opening a new one
This PR adds a new `--reuse` (`-r`) CLI flag that allows users to
replace the workspace in an existing Zed window instead of opening a new
one or adding files to the current workspace.
### What it does
The `--reuse` flag finds an available local workspace window and
replaces its workspace with the newly specified paths. This provides a
third workspace opening mode alongside the existing `--add` and `--new`
flags.
### Implementation Details
- **CLI Flag**: Added `--reuse` (`-r`) flag with proper mutual exclusion
with `--add` and `--new`
- **Window Replacement**: Uses the existing `replace_window` option in
`workspace::OpenOptions`
- **Window Selection**: Reuses the first available local workspace
window
- **Fallback Behavior**: When no existing windows are found, creates a
new window
- **Test Coverage**: Added comprehensive test for the reuse
functionality
### Behavior
- `zed -r file.txt` - Replaces the workspace in an available window with
`file.txt`
- If no windows are open, creates a new window (same as default
behavior)
- Mutually exclusive with `-a/--add` and `-n/--new` flags
- Works with multiple files and directories
### Files Changed
- `crates/cli/src/cli.rs` - Added `reuse` field to `CliRequest::Open`
- `crates/cli/src/main.rs` - Added CLI argument definition and parsing
- `crates/zed/src/zed/open_listener.rs` - Implemented reuse logic and
added tests
- `crates/zed/src/zed/windows_only_instance.rs` - Updated for Windows
compatibility
### Testing
- ✅ Unit tests pass
- ✅ Manual testing confirms expected behavior:
- Works when no windows are open
- Replaces workspace in existing window
- Maintains compatibility with existing `-a` and `-n` flags
- Proper help text display
## Manual testing
#### In this first video we do a couple of tests:
* **1**: What happens if we use the -r flag when there are no windows
open?
- works as expected. It opens the files in a new window.
* **2**: Does it work as expected if there is already a window open.
Does it overrides the workspace?
- yes it does. When opening a different file it overrides the current
window instead of creating a new one.
* **3**: Does the -n flag still works as expected?
- yes, it creates the project in a new window
* **4**: What about the -a flag?
- yes, on the last accessed page
* **5**: we do the replace command. It overrides the first opened
window, do we want this behavior?
- It is good enough that it overrides one of the opened windows with the
new project. It still makes the user automatically go to the window with
the specified files
* **6**: we use the -r command again replacing the workspace with a new
one.
- this indeed worked as expected
https://github.com/user-attachments/assets/f1cd7f4b-f4af-4da2-a755-c0be7ce96c0d
#### In here the we check how the --help flag now displays the new
command. (Description was later updated)
https://github.com/user-attachments/assets/a8a7a288-d926-431b-a9f9-a8c3d909a2ec
We've been considering removing workspace-hack for a couple reasons:
- Lukas ran into a situation where its build script seemed to be causing
spurious rebuilds. This seems more likely to be a cargo bug than an
issue with workspace-hack itself (given that it has an empty build
script), but we don't necessarily want to take the time to hunt that
down right now.
- Marshall mentioned hakari interacts poorly with automated crate
updates (in our case provided by rennovate) because you'd need to have
`cargo hakari generate && cargo hakari manage-deps` after their changes
and we prefer to not have actions that make commits.
Currently removing workspace-hack causes our workspace to grow from
~1700 to ~2000 crates being built (depending on platform), which is
mainly a problem when you're building the whole workspace or running
tests across the the normal and remote binaries (which is where
feature-unification nets us the most sharing). It doesn't impact
incremental times noticeably when you're just iterating on `-p zed`, and
we'll hopefully get these savings back in the future when
rust-lang/cargo#14774 (which re-implements the functionality of hakari)
is finished.
Release Notes:
- N/A
No need to clutter the `--help` docs with default directories for
platforms other than the current one.
Release Notes:
- N/A
Co-authored-by: David Kleingeld <davidsk@zed.dev>
Closes#34393
Currently, we’re using `zed.exe --askpass` kind of like an `nc`
substitute, it prints out the SSH password to stdout with something like
`println!("user-pwd")`. `ssh.exe` then reads the password from stdout so
it can establish the connection.
The problem is that in release builds we set `subsystem=windows` to
avoid Windows spawning a black console window by default. The side
effect is that `zed.exe` no longer has a stdout, so `ssh.exe` can’t read
the password.
Through testing, I confirmed that neither allocating a new console for
`zed.exe` nor attaching it to the parent process’s stdout resolves the
issue. As a result, this PR updates the implementation to use `cli.exe
--askpass` instead.
TODO:
- [ ] Check that the `cli` path is correct on macOS
- [ ] Check that the `cli` path is correct on Linux
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
std commands can block for an arbitrary duration and so runs risk of
blocking tasks for too long. This replaces all such uses where sensible
with async processes.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
This removes around 900 unnecessary clones, ranging from cloning a few
ints all the way to large data structures and images.
A lot of these were fixed using `cargo clippy --fix --workspace
--all-targets`, however it often breaks other lints and needs to be run
again. This was then followed up with some manual fixing.
I understand this is a large diff, but all the changes are pretty
trivial. Rust is doing some heavy lifting here for us. Once I get it up
to speed with main, I'd appreciate this getting merged rather sooner
than later.
Release Notes:
- N/A
I've recently disabled Spotlight on my Mac and found that this code path
(which I rely on a lot) ceased working for me.
Closes #ISSUE
Release Notes:
- N/A
Remove the local `RELEASE_CHANNEL` source that seems to be used only for
Linux as opposed to `channel_release::CHANNEL_RELEASE_NAME` for other
platform
Windows:
eee1b1f8a8/crates/cli/src/main.rs (L681-L685)
Release Notes:
- N/A
Removes a manual implementation of `std::io::copy`. The internal buffer
of `std::io::copy` is also 8 kB and behaves exactly the same. On Linux
`std::io::copy` also has access to some better performing file copying.
Release Notes:
- N/A
The installer, uninstaller, and the Zed binary files are all signed
using Microsoft’s newly launched Trusted Signing service. For
demonstration purposes, I have used my own account for the signing
process.
For more information about Trusted Signing, you can refer to the
following links:
- [Microsoft Security Blog: Trusted Signing is in Public
Preview](https://techcommunity.microsoft.com/blog/microsoft-security-blog/trusted-signing-is-in-public-preview/4103457)
- [Overview of Azure Trusted
Signing](https://learn.microsoft.com/en-us/azure/trusted-signing/overview)
**TODO:**
- [x] `InnoSetup` script to setup an installer
- [x] Signing process
- [x] `Open with Zed` in right click context menu (by using sparse
package)
- [x] Integrate with `cli`
- [x] Implement `cli` (#25412)
- [x] Pack `cli.exe` into installer
- [x] Implement auto updating (#25734)
- [x] Pack autoupdater helper into installer
- [x] Implement dock menus
- [x] Add `Recent Documents` entries (#26369)
- [x] Make `zed.exe` aware of sigle instance (#25412)
- [x] Properly handle dock menu events (#26010)
- [x] Handle `zed://***` uri
**Materials needed:**
- [ ] Icons
- [ ] App icon for all channels (#9571)
- [ ] Associated file icons, at minimum a default icon
([example](https://github.com/microsoft/vscode/tree/main/resources/win32))
- [ ] Logos for installer wizard
- [ ] Icons for appx
- [x] Code signing
- [x] Secrets: AZURE_TENANT_ID, AZURE_CLIENT_ID, AZURE_CLIENT_SECRET,
ACCOUNT_NAME, CERT_PROFILE_NAME
- [x] Other constants: ENDPOINT, Identity Signature (i.e. `CN=Junkui
Zhang, O=Junkui Zhang, L=Wuhan, S=Hubei, C=CN`)
https://github.com/user-attachments/assets/4f1092b4-90fc-4a47-a868-8f2f1a5d8ad8
Release Notes:
- N/A
---------
Co-authored-by: Kate <kate@zed.dev>
Co-authored-by: localcc <work@localcc.cc>
Co-authored-by: Peter Tripp <peter@zed.dev>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
This PR contains a set of changes for improving FreeBSD support (#15309,
#29550) and is a kind of follow up to the PR #20480 which added an
initial support for FreeBSD.
A summary of changes is as follows:
- Add some more freebsd conditionals which seem missing in the previous
PR.
- Implement `anonymous_fd()` and `current_path()` functions for FreeBSD.
- Improve detection of FreeBSD in telemetry and GPU detection.
- Temporarily disable LiveKit/WebRTC support to make build succeed.
- Remove support for flatpak since it is Linux-only packaging format.
Adding `RUSTFLAGS="-C link-dead-code"` does not seem necessary anymore.
It builds fine without the flag.
Known issues:
- Integrated terminal is painfully laggy and virtually unusable in my
environment. This might be specific to my setup.
- I cannot input Japanese using IME. When I type characters, they appear
on the screen. But when I hit return key, they disappears. Seems the
same issue as #15409.
My environment is MATE desktop on X11 on FreeBSD 14.2 on Intel Core
i5-7260U integrated graphics.
P.S. For those who might be interested, a work-in-progress FreeBSD port
and binary packages are available at
https://github.com/tagattie/FreeBSD-Zed
Release Notes:
- N/A
---------
Co-authored-by: Peter Tripp <peter@zed.dev>
Todo:
* [x] Open diffed files as regular buffers
* [x] Update diff when buffers change
* [x] Show diffed filenames in the tab title
* [x] Investigate why syntax highlighting isn't reliably handled for old
text
* [x] remove unstage/restore buttons
Release Notes:
- Adds `zed --diff A B` to show the diff between the two files
---------
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
Co-authored-by: Agus Zubiaga <agus@zed.dev>
In #31331, I made a change that prevents Zed from running with root
privileges, but I forgot about the CLI.
So if you run the CLI without the `--foreground` flag, it just freezes
without any messages. This PR fixes that.
Release Notes:
- N/A
https://github.com/zed-industries/zed/issues/30972 brought up another
case where our context is not enough to track the actual source of the
issue: we get a general top-level error without inner error.
The reason for this was `.ok_or_else(|| anyhow!("failed to read HEAD
SHA"))?; ` on the top level.
The PR finally reworks the way we use anyhow to reduce such issues (or
at least make it simpler to bubble them up later in a fix).
On top of that, uses a few more anyhow methods for better readability.
* `.ok_or_else(|| anyhow!("..."))`, `map_err` and other similar error
conversion/option reporting cases are replaced with `context` and
`with_context` calls
* in addition to that, various `anyhow!("failed to do ...")` are
stripped with `.context("Doing ...")` messages instead to remove the
parasitic `failed to` text
* `anyhow::ensure!` is used instead of `if ... { return Err(...); }`
calls
* `anyhow::bail!` is used instead of `return Err(anyhow!(...));`
Release Notes:
- N/A
This PR introduces support for a `--user-data-dir` CLI flag to override
Zed's data directory and proposes renaming `support_dir` to `data_dir`
for better cross-platform clarity. It builds on the discussion in #25349
about custom data directories, aiming to provide a flexible
cross-platform solution.
### Changes
The PR is split into two commits:
1. **[feat(cli): add --user-data-dir to override data
directory](https://github.com/zed-industries/zed/pull/26886/commits/28e8889105847401e783d1739722d0998459fe5a)**
2. **[refactor(paths): rename support_dir to data_dir for cross-platform
clarity](https://github.com/zed-industries/zed/pull/26886/commits/affd2fc606b39af1b25432a688a9006229a8fc3a)**
### Context
Inspired by the need for custom data directories discussed in #25349,
this PR provides an immediate implementation in the first commit, while
the second commit suggests a naming improvement for broader appeal.
@mikayla-maki, I’d appreciate your feedback, especially on the rename
proposal, given your involvement in the original discussion!
### Testing
- `cargo build `
- `./target/debug/zed --user-data-dir ~/custom-data-dir`
Release Notes:
- Added --user-data-dir CLI flag
---------
Signed-off-by: Marko Kungla <marko.kungla@gmail.com>
