# cli: Respect \`\-\-new\` when opening URLs from the CLI \(\#54408\) · gitcafe/zed

[View on GitCafe](https://git.cafe/gitcafe/zed/commit/0f6ebdd26908734c505597dac4f82546f75129f0)

Repository: [gitcafe/zed](https://git.cafe/gitcafe/zed)

Visibility: public

Requested revision: 0f6ebdd26908734c505597dac4f82546f75129f0

Requested commit: 0f6ebdd26908734c505597dac4f82546f75129f0

Commit: 0f6ebdd26908734c505597dac4f82546f75129f0

Tree: 1ee60d5695e1d161f661ffa616dff65f78b90a3a

Author: Tom Houlé

Committer: GitHub

## Message

```
cli: Respect `--new` when opening URLs from the CLI (#54408)

`zed --new ssh://host/path/to/file` only created a new window on the
first call. Subsequent invocations silently reused the existing SSH
workspace for the same host, which then tried to open the new path
against the existing worktree and surfaced a
`DevServerProjectPathDoesNotExist` popup when the path didn't belong to
any open worktree.

The CLI correctly translated `--new` to `OpenBehavior::AlwaysNew`, but
the URL branch of `handle_cli_connection` dropped the `open_behavior`.
`handle_open_request` then called `open_remote_project` (and
`open_paths_with_positions` for `file://`) with
`OpenOptions::default()`, which is `WorkspaceMatching::MatchExact`, so
any existing SSH window for the same host won the match. The issue
applies to `file://` URLs and `-a` / `-e` / `--reuse` for URL-shaped
arguments in general; `--new` was just the most visible symptom.

The fix is making sure the translation of `OpenRequest` is uniform
across plain paths and URL-shaped arguments.

Closes #52679.

Release Notes:

- Fixed `zed --new ssh://host/path` reusing an existing SSH window
instead of opening a new one. This also applied to other URL-shaped path
arguments.
```

## Parents

- [068d64edd637be2e7e2a44b99ef4965550885b67](https://git.cafe/gitcafe/zed/commit/068d64edd637be2e7e2a44b99ef4965550885b67?format=markdown)

[Source at this commit](https://git.cafe/gitcafe/zed/tree/0f6ebdd26908734c505597dac4f82546f75129f0?format=markdown)