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