Remote projects with identical paths on different SSH hosts can become ambiguous

[yuzhichang]

Bug summary

Emdash appears to assume that a project path uniquely identifies a project. That breaks down for remote projects when two different SSH hosts expose repositories at the same path, for example:

• host-a:/srv/repo
• host-b:/srv/repo

In that setup, some operations can no longer safely infer which remote project the user meant if the API surface only passes a path.

Why this matters

For remote projects, path-only lookup can lead to one of two bad outcomes:

1. the app picks an arbitrary matching remote project and performs the operation on the wrong host
2. the app has no principled way to disambiguate the target at all

This affects correctness, not just UX.

Reproduction idea

1. Configure two SSH connections pointing at different hosts.
2. On both hosts, make sure the repository exists at the same absolute path, for example /srv/repo.
3. Add both remote projects to Emdash.
4. Trigger remote operations that identify the project only by path or worktree path.

Examples of affected categories:

• worktree operations
• PR / GitHub CLI flows
• branch and status lookups
• commit history and diff lookups

Expected behavior

If multiple remote projects share the same path:

• operations should succeed only when the target can be uniquely identified
• otherwise the app should require an explicit disambiguator such as project id or SSH connection id
• the app should never silently choose the first matching project

Actual behavior

The current model seems to retain path-based assumptions at the API / resolver layer, which makes multi-host same-path remotes ambiguous.

Design question

Would you prefer to solve this by:

1. treating remote project identity as something like (path, sshConnectionId)
2. pushing projectId / sshConnectionId explicitly through more IPC and renderer call chains
3. introducing a shared locator type so path-only lookups are limited to cases that are provably unambiguous

I’m opening this mainly to get maintainers’ feedback on the preferred direction before more code is pushed into a larger change set.