Feature Request: support repositories hosted on external Git providers (for example Azure DevOps Repos)

No se nombran archivos fuente, pruebas ni puntos de entrada; empieza por localizar la creación de sesiones y la gestión de la autenticación de repositorios en el SDK. Se considera terminado cuando se puede usar un remoto accesible que no sea de GitHub con credenciales proporcionadas por quien realiza la llamada, mientras que las capacidades específicas del host que no estén disponibles producen errores claros y documentados.

Problem

Session creation and repository-aware behavior assume a repository hosted on GitHub. Many organizations adopting Copilot keep a substantial amount of source in other Git hosts and cannot migrate it in the near term. Azure DevOps Repos is a common example: an organization may use GitHub for some work while its primary product repositories remain in Azure DevOps.

Those repositories are currently out of reach for agent sessions, which forces teams either to exclude their primary codebases from agent workflows or to mirror them into GitHub, which introduces drift and additional governance burden.

What is missing

• No supported way to point a session at a repository hosted on a different Git provider, such as Azure DevOps Repos.
• No documented contract describing which capabilities require GitHub hosting (for example pull request creation or issue linking) and which only require a Git working tree.

Proposed behavior

• A session can target any reachable Git remote, authenticated through a caller-supplied credential.
• Capabilities that genuinely require GitHub-specific APIs degrade explicitly, with a clear capability error, rather than failing in an undifferentiated way.
• Code-level capabilities that only need a working tree — reading, editing, running commands, running tests, producing a diff or a patch — work regardless of the host.
• Documentation states clearly which features are host-agnostic and which are GitHub-specific.

Example scenario

An organization's application code lives in Azure DevOps Repos while its shared open-source dependencies live on GitHub. The team wants the agent to investigate and patch the Azure DevOps repository and return a reviewable change, using an Azure DevOps credential supplied by the caller.

Acceptance criteria

• A repository on a non-GitHub Git remote, such as Azure DevOps Repos, can be used as the session working tree.
• Authentication for that remote is caller-supplied and not required to be a GitHub credential.
• Host-specific capabilities return a clear, documented capability error when unavailable.