plugin install ignores macOS system git credentials

[imod]

Describe the bug

When installing a plugin from a private Git host over HTTPS, copilot plugin install fails with a redirect error — even when git ls-remote works correctly against the same URL using system git credentials.

The installer appears to spawn its own HTTP/git process that does not inherit macOS Keychain credentials, Git credential helpers (osxkeychain), or credentials stored via git config --global credential.helper store. As a result, the first unauthenticated request is redirected to the host's sign-in page, and the installer then attempts to clone that redirect URL verbatim instead of handling the 302 and retrying with credentials.

Environment

• OS: macOS (Apple Silicon)
• Git host: Self-hosted GitLab instance (private, authentication required)

Affected version

GitHub Copilot CLI 1.0.12

Steps to reproduce the behavior

1. Set up access to a private Git host requiring authentication
2. Configure macOS git credentials via osxkeychain (the macOS default)
3. Verify that git ls-remote https://<private-git-host>/<org>/<repo>.git works correctly and returns refs without prompting
4. Run: copilot plugin install https://<private-git-host>/<org>/<repo>.git

Expected behavior

copilot plugin install should respect the system git credential chain, including:

• macOS Keychain (osxkeychain)
• git config --global credential.helper store
• Any credentials configured via git config --global credential.<host>.username

This is consistent with how git clone and git ls-remote behave on the same machine.

Additional context

The installer makes an unauthenticated request, receives a 302 redirect to /users/sign_in, and then tries to clone that redirect URL instead of the original:

Failed to install plugin: Failed to fetch git plugin from the provided URL.
Details: Error: Command failed: git clone --depth 1 https://<private-gitlab-host>/users/sign_in /path/to/cache/...
Cloning into '/path/to/cache/...'...
fatal: unable to update url base from redirection:
  asked for: https://<private-gitlab-host>/users/sign_in/info/refs?service=git-upload-pack
   redirect: https://<private-gitlab-host>/users/sign_in

A fix could involve:

• Delegating the clone to the system git binary (which inherits all configured credential helpers)
• Or invoking git credential fill before the clone attempt to pre-populate credentials

[pbailey-hf]

I am getting the same error on WSL

[examon]

This should be resolved as of v1.0.15. The plugin installer was incorrectly following HTTP redirects before handing some repository URLs to git, which could cause it to try cloning the redirect target (for example, a sign-in page) instead of the actual repository. Starting with v1.0.15, redirect resolution is limited to specific known URLs, so private or self-hosted Git URLs are passed unchanged to git and your system credential helpers can handle authentication normally. If you're still seeing this on v1.0.15 or later, please feel free to reopen this issue.