github.copilot.git.repository not populated for self-hosted GitHub Enterprise Server remotes with custom domains
- Dominant language
- TypeScript
- Stars
- 193k
- Forks
- 42.4k
- PR merge metrics
- PR metrics pending
Description
Does this issue occur when all extensions are disabled?: Yes
- VS Code Version: 1.132.0
- OS Version: macOS 26.5.2 (arm64)
Steps to Reproduce:
1. Open a workspace whose `origin` remote points to a self-hosted GitHub Enterprise
Server instance with a custom domain (e.g. `https://git.mycompany.com/owner/repo.git`)
— NOT `github.com` or a `*.ghe.com` cloud tenant.
2. Enable Copilot Chat OTel export: `"github.copilot.chat.otel.enabled": true`,
`"github.copilot.chat.otel.exporterType": "console"` (or point at a debug OTLP
collector).
3. Trigger any Copilot Chat agent turn (agent mode).
4. Inspect the resulting `invoke_agent` span attributes.
**Expected:** per the [OTel monitoring docs](https://code.visualstudio.com/docs/agents/guides/monitoring-agents),
`github.copilot.git.repository` (and legacy `copilot_chat.repo.remote_url`) should
be present "when in a Git repo."
**Actual:** `github.copilot.git.branch` and `github.copilot.git.commit_sha` ARE
present and correct, but `github.copilot.git.repository`,
`copilot_chat.repo.remote_url`, and `github.copilot.github.org` are always absent
for this remote — with no error, just silently missing.
**Root cause** (found in the bundled `copilot-chat` extension, v0.60.0,
`dist/extension.js`): the repo-URL attribute is only set if a repo ID can be
derived via:
function iE(n){
let e=Qj(n); if(!e) return;
let r=["github.com","ghe.com"].find(s=>e.host===s||e.host.endsWith("."+s));
if(!r) return;
...
}
`iE()` only recognizes `github.com` and `*.ghe.com` (GitHub's cloud-hosted
Enterprise product). The fallback `vEt()` only handles Azure DevOps
(`dev.azure.com`/`ssh.dev.azure.com`). A self-hosted GHES instance with a custom
domain matches neither allowlist, so the remote is silently dropped and
`remoteUrl` never gets set — even though `headBranchName`/`headCommitHash` are
read directly off the same repo object with no such host check.
**Suggested fix:** don't gate repo-URL population on a hostname allowlist. Any
parseable git remote URL has an `owner/repo`-shaped path; the current design
silently drops all non-github.com/ghe.com/Azure DevOps hosts (self-hosted GHES,
GitLab, Bitbucket Server, generic git servers, etc.) even though branch/commit
already work for all of them.
Contributor guide
Assessment
This issue has not been assessed yet.