Clone: fall back to SSH when an HTTPS remote fails auth and a key is present - #3
Merged
Conversation
Mission Control derives the clone remote from the selected repo's origin, which is commonly an HTTPS URL, while a sandbox is typically provisioned with SSH auth only. Git never uses an SSH key for an https:// remote, so cloning a private repo fails with 'could not read Username for https://github.com: terminal prompts disabled'. When an HTTPS clone fails with a credentials error AND a private key is present under ~/.ssh, derive the equivalent SSH remote (git@host:owner/repo.git) and retry once. Surgical by design: public repos still clone over HTTPS (no auth failure, no fallback); non-auth failures (repo-not-found, network) surface as-is; URLs that already carried credentials are not silently switched. deriveSshFallbackRemote is a pure, unit-tested function; GitRpc gains an injectable sshDir (defaulting to ~/.ssh, matching SshRpc). Root cause also worth fixing upstream in Mission Control (send an SSH remote when the sandbox uses SSH auth, or support an HTTPS token); this is the agent-side safety net.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
When a repo is selected from local disk, Mission Control derives the clone remote from its
origin. That origin can be HTTPS or SSH, depending on how the user has the repo configured on their machine. If it's an HTTPS URL but the sandbox is provisioned with SSH auth only (a key under~/.ssh), the clone fails — git never uses an SSH key for anhttps://remote — and the provisioned key is never used:Fix
In
GitRpc.clone, when an HTTPS clone fails with a credentials error and a private key exists under~/.ssh, derive the equivalent SSH remote (git@host:owner/repo.git) and retry once. Surgical:deriveSshFallbackRemoteis a pure, unit-tested function;GitRpcgains an injectablesshDir(defaulting to~/.ssh, matchingSshRpc).Testing
6 unit tests added (GitHub,
.gitsuffix, GitLab subgroups, non-auth failure, no-key, SSH/credentialed/host-root rejection).typecheck,lint, git-rpc tests, andbuildpass.