stablyai/orca · error

Remote connection dropped. Click Reconnect on the SSH target

Error message

Remote connection dropped. Click Reconnect on the SSH target before retrying.

What it means

assertRemoteUrlReadable throws this (the SSH_GIT_PROVIDER_UNAVAILABLE_MESSAGE constant) when RemoteUrlProbeContext.connectionId is set but getSshGitProvider(connectionId) returns undefined — i.e. the SSH relay was the intended transport for the probe, but the git provider for that connection has been unregistered (connection dropped, relay torn down, or never fully came up). The probe refuses to return a cached 'no remote' answer because the lookup never got to ask; it surfaces an explicit 'reconnect' instruction instead.

Source

Thrown at src/main/git/remote-url-probe.ts:104

  if (parts.length === 0) {
    parts.push(String(error))
  }
  const text = parts.join('\n')
  return TRANSIENT_PROBE_PATTERNS.some((pattern) => pattern.test(text))
}

/**
 * Throws when the remote could not be read because the probe was wedged or its
 * transport was gone, and returns normally for every answer — including a repo
 * with no remote at all. Lets a caller that treats "nothing found" as a cacheable
 * answer tell that apart from a lookup that never got to ask.
 */
export async function assertRemoteUrlReadable(
  context: RemoteUrlProbeContext,
  remoteName = 'origin'
): Promise<void> {
  if (context.connectionId && !getSshGitProvider(context.connectionId)) {
    throw new Error(SSH_GIT_PROVIDER_UNAVAILABLE_MESSAGE)
  }
  try {
    await readRemoteUrl(context, remoteName)
  } catch (error) {
    if (isTransientGitProbeError(error)) {
      throw error
    }
  }
}

View on GitHub (pinned to 1136503c6a)

Solutions

1. Trigger the SSH target reconnect flow, then re-run the probe with the same connectionId (reconnect re-registers the provider).
2. Before probing, check that the SSH target is still in 'connected' state for connectionId; if not, prompt reconnect rather than probing.
3. Do not cache connectionId across long-lived UI panels without a liveness check — reconnects bump the generation and invalidate old ids.
4. If the probe is part of a cache-fill loop, treat this error as 'unavailable, retry later' rather than caching a negative answer.

Example fix

// before
await assertRemoteUrlReadable({ repoPath, connectionId })

// after: verify the provider is live, prompt reconnect if not
import { getSshGitProvider } from '../providers/ssh-git-dispatch'
if (connectionId && !getSshGitProvider(connectionId)) {
  await promptSshReconnect(connectionId)
}
await assertRemoteUrlReadable({ repoPath, connectionId })

import { getSshGitProvider } from '../providers/ssh-git-dispatch'

function sshProbeReady(context: RemoteUrlProbeContext): boolean {
  return !context.connectionId || Boolean(getSshGitProvider(context.connectionId))
}

// Before probing:
if (!sshProbeReady(context)) {
  await promptSshReconnect(context.connectionId)
}

import { SSH_GIT_PROVIDER_UNAVAILABLE_MESSAGE } from '../providers/ssh-git-dispatch'

function isSshGitProviderUnavailable(error: unknown): boolean {
  return error instanceof Error && error.message === SSH_GIT_PROVIDER_UNAVAILABLE_MESSAGE
}

try {
  await assertRemoteUrlReadable(context)
} catch (error) {
  if (isSshGitProviderUnavailable(error)) {
    await promptSshReconnect(context.connectionId)
    return  // caller should re-run the probe after reconnect
  }
  throw error
}

When it happens

Trigger: Calling assertRemoteUrlReadable({ repoPath, connectionId }) or readRemoteUrl with a connectionId whose SSH connection was disconnected (relay dropped, user disconnected, or provider was unregistered by a generation bump) after the caller cached the connectionId but before the probe ran. Also when the SSH target is mid-reconnect and the new provider is not yet registered.

Common situations: An SSH connection that silently dropped between the time the UI captured connectionId and the time a forge integration ran the URL probe; reconnecting the SSH target in another pane while a review/PR probe is in flight; a crash-restart of the SSH relay that bumped provider generations without the caller noticing; using a connectionId from a previous session after the relay restarted.

Related errors

• SSH target "${input.target.connectionId}" is not connected.
• SSH target did not connect: ${state.status}
• SSH Git provider is not available. Reconnect to this target
• SSH Git provider is not available. Reconnect to this target
• No SSH connection for "${connectionId}"

AI-assisted analysis of stablyai/orca@1136503c6a (2026-08-12). Data as JSON: /api/errors/1706fac8180817f2. Report an issue: GitHub.