[OrcaWin]

	Files	Added	Deleted	Net
Test	14	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​322	$\color{#cf222e}{\Huge{\mathbf{−}}}$​45	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​277
Prod	13	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​100	$\color{#cf222e}{\Huge{\mathbf{−}}}$​66	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​34

ELI5

The same project can be registered on two machines, and both copies can share one ID. When you removed one machine's copy, Orca sometimes looked the project up by ID alone and removed the other machine's working copy instead. Now every removal names the machine it is for, and Orca removes only that machine's copy.

What Changed

Before: removing a project took an optional host. Without it, the lookup fell back to "the only row with this ID" or "the row on the machine currently in focus". If the copy you meant had already dropped out of the list (for example after a refresh), the only remaining row belonged to a different machine, so Orca killed that machine's terminals, purged its workspaces, and dropped its project. Two internal callers never passed a host: the cleanup that removes projects after their cloud VM is destroyed, and group deletion when a group held the same project ID on two machines.

After:

• Removing a project requires a host. The type change makes the compiler reject any caller that omits it.
• The removal matches that host's row exactly. If that host has no row, nothing is removed, and the other machine's project is left alone.
• The VM cleanup passes each orphaned row's own host.
• Deleting a group together with its projects removes exactly the rows that were members of the group (or its subgroups), each on its own host. The member list (project ID plus host) is captured before the group is deleted, because deleting the group clears membership. A row with the same ID on another host that is not in the group is left alone, even when the group's catalog also holds that host's rows. Before, a duplicate ID was guessed from focus, then reported as "failed" even when it was later removed. A group with no recorded owner acts on the machine in focus, but still only on a row that is actually a member.
• Removing a project on this machine's catalog (local or direct SSH, git or folder) always asks the main process to remove that one host's row. Before, the sidebar checked its own copy of the list for a same-ID row on another host, and if it saw none it sent an ID-only removal. That copy can be out of date: another window or a paired client may have just added the other host's row, or a refresh may still be pending. The ID-only removal then deleted every host's row and that host's saved workspace details.
• The saved catalog itself now refuses an ID-only removal when rows on more than one host share that ID, and throws instead of deleting them all. The runtime repo.rm call already resolved a single row and removes it by host. The two "undo a half-finished project setup" paths now remove the new row by its host too.
• The remove-project dialog does nothing if it was opened without a host, instead of guessing. Both sidebar entry points already pass one. The "delete main worktree" entry point now always passes the worktree's host.

Why

The root cause was the bare-ID fallback in the removal path, not any one caller. Requiring the host in the type closes the whole class of bug, and it fixes the callers the compiler found. This was preferred over adding guards one caller at a time (the approach in #13117), which leaves the fallback in place for the next caller to hit. For the same reason the sidebar no longer decides between a narrow and a broad delete from its own copy of the list, which can be stale. The saved catalog, which is the authoritative copy, enforces the rule as well. The fallbacks stay in findRepoForHost for read-only display lookups, where a wrong guess cannot destroy data.

The scope is narrowed to project removal. #14603 (GitLab tasks on a remote host) has a different cause: GitLab calls are not relayed to the owning host over RPC. It also needs a decision about where GitLab credentials live, so it is not included here.

Linked Issue

Fixes #13071

Visual Proof

N/A. Nothing visible changes. The fix only changes which host's project row a removal acts on.

Testing

• New file project-removal-owner-host.test.ts covers five cases:

  • Host A's row is gone, so host B's row is the only one with that ID; removing on host A leaves host B untouched.
  • The destroyed-VM purge removes only the SSH row and keeps the local project with the same ID. This fails without the fix.
  • Deleting an owned group removes both of its same-ID rows on their own hosts and leaves another host's row alone. This fails without the fix.
  • Deleting a group leaves a same-ID SSH row that sits in a different group untouched. This fails without the fix.
  • Deleting a group with no recorded owner removes its SSH member, not the focused machine's same-ID row outside the group. This fails without the fix.

• Stale-catalog cases in project-removal-owner-host.test.ts: the sidebar sees only one host's row while the main catalog holds both. They cover git and folder projects, local and direct SSH removal, and a selected row that main has already dropped. All five fail without the fix.

• persistence-duplicate-repo-id-host-scope.test.ts: on the real store, an ID-only removal of an ID that two hosts share throws and keeps both rows and the SSH host's saved workspace details, for git and folder projects.

• Existing tests now pass an explicit host. The one group-deletion test that expected the spurious "failed" entry now expects a clean result.

• Checks run: pnpm tc, oxlint, check:code-quality:changed, and src/renderer/src/store, components/sidebar, components/settings, src/main/ipc, src/main/runtime and the persistence suites (about 27,000 tests). profile-state-backup-rotation.test.ts times out the same way on the previous head, so that failure is unrelated to this change.

• Real-host check not done. Reproducing this needs two hosts publishing the same project ID while one host's row is missing from the list, or a destroyed cloud-VM SSH target. A Docker SSH fixture cannot produce either state. The routing decision happens in the client, so the unit tests exercise the exact code path.

• I manually tested these changes locally

• Automated tests added/updated, or explained why not below

AI Disclosure

Written with Claude Code.

Review

Agent skill upstream boundary

• Not applicable, or this change follows docs/reference/agent-skill-sharing-upstream-boundary.md and copies or mechanically translates no upstream skill-installer source, tests, fixtures, registry entries, path tables, comments, or documentation.

Notes

Remote compatibility: there are no wire changes. The client uses the same repo.rm and repos:removeForHost calls, now always aimed at the named host. Older paired clients still send repo.rm with a selector. The host resolves that selector to one row (a bare ID shared by two hosts was already rejected) and removes it by host, so their behavior does not change. repos:remove is still available to callers in the same build. It now fails, instead of deleting every host's row, only when the ID belongs to more than one host. SSH, local, runtime and folder-workspace projects all go through the same exact-host match.

Checklist

• This PR is small and focused
• I explained what changed and why (ELI5, the user-facing before/after, the mechanism, and why over the alternatives)
• Before/after screenshots or videos attached for UI changes, or N/A with reason
• Self-reviewed for correctness, security, and performance
• Cross-platform, SSH/remote, and path/shortcut impact considered (or N/A)
• pnpm lint, pnpm typecheck, pnpm test, and pnpm build pass (or CI will cover; local preferred)