mirror of
https://github.com/stablyai/orca.git
synced 2026-09-29 08:03:20 +00:00
Neil
d084a2a36a
`repoIsRemote` read `repo.connectionId` directly. That is one of four spellings of host ownership, so the predicate was wrong in both directions: a row carrying only `executionHostId: 'ssh:<target>'` read as local and got the Linux-only `orca-ide` rename it cannot resolve through the relay shim, while a row that declares itself `local` with a stale `connectionId` read as remote and lost the rename it needs on a Linux desktop. The predicate now resolves the host first and asks "does an SSH target hold this row's files" via `getRepoSshConnectionId`. That keeps a `runtime:` host's nested SSH target remote (that machine reaches the files through its own relay shim) while a runtime with no nested target - a full Orca install - stays local, as do WSL and local. Its call sites did not all want that question: - The four launch-scope sites in main already hold the resolved PTY route on `TerminalWorkspaceLaunchScope.connectionId`. `scope.repo` is documented display metadata and can be a row from a different host than the worktree names, so they now read the route they will actually spawn on. A launch shape that disagrees with its own route is the bug, not a second predicate. - `launchAgentInNewTab` picked its repo row with a host-blind `store.repos.find`, so a worktree that names its own host could be shaped by another host's row. It now resolves through `getConnectionIdFromState`, the same rule the file already used for transcript readability. - `resolveAgentBackgroundLaunchHost` derived the route, the trust write and the launch shape from three reads of the raw field; one resolution now feeds all three. Also converts the raw `repo.connectionId` agent-detection probe eight lines above `buildWorktreeStartupForDraft`'s launch shape, which #17919 deferred precisely because converting it alone would have left that file internally inconsistent. Tests cover two distinct SSH hosts (a single-host fixture passes even when the answer comes off the wrong row, which is how the `ssh:m4air` -> openclaw leak survived review) and a `runtime:` host carrying a nested SSH target.
27 lines
1.6 KiB
TypeScript
27 lines
1.6 KiB
TypeScript
import type { Repo } from './repo-types'
|
|
import { getRepoSshConnectionId } from './execution-host'
|
|
|
|
/**
|
|
* Why: a repo reached over SSH runs the Orca CLI through the relay shim, which is always deployed
|
|
* as plain `orca` (Unix) / `orca.cmd` (Windows). The Linux-only `orca-ide` rename — which exists
|
|
* solely to avoid shadowing the GNOME Orca screen reader on a local desktop — must not be applied
|
|
* to those remotes, or `orca-ide claude-teams` lands on a PATH where it does not exist.
|
|
*
|
|
* The question is "does an SSH target hold this row's files", not "what may this client dial", so
|
|
* it resolves the execution host instead of reading the raw `connectionId` field. SSH ownership has
|
|
* two spellings and the raw read is wrong in both directions:
|
|
*
|
|
* - a row carrying only `executionHostId: 'ssh:<target>'` reads as local and gets the `orca-ide`
|
|
* rename it cannot resolve on the remote;
|
|
* - a row that declares itself `local` while a stale `connectionId` survives reads as remote and
|
|
* loses the rename it needs on a Linux desktop.
|
|
*
|
|
* `runtime:<env>` keeps its nested SSH target (that machine reaches the files through its own relay
|
|
* shim), while a runtime host with no nested target is a full Orca install and stays false — as do
|
|
* WSL and local. Callers routing a client-local PTY want `getSshTargetIdForExecutionHost` instead;
|
|
* callers that already hold a resolved launch connection should read that, not re-derive here.
|
|
*/
|
|
export function repoIsRemote(repo: Pick<Repo, 'connectionId' | 'executionHostId'>): boolean {
|
|
return getRepoSshConnectionId(repo) !== null
|
|
}
|