[Bug]: link_pull_request rejects a PR URL on a GitHub Enterprise host #16070

Activity

1. mkielar

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Oct 5, 2026
2. juliusmarminge commented on Oct 5, 2026

   

   juliusmarminge

   on Oct 5, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Triage

   Thanks for the clear repro, @mkielar. The contrast between the URL call and the host + repository + number call made this easy to pin down.

   What I found

   • On current main (781223057) and on 37de6cbde65c (0.0.46-nightly.20261005.2667), link_pull_request still runs a url through parseChangeRequestUrl in packages/shared/src/changeRequestUrl.ts. A /owner/repo/pull/N path is treated as GitHub only when the hostname is github.com, a *.github.com subdomain, or has github as a DNS label (isHostOf).
   • A host like my-awesome-company.ghe.com misses that check. *.ghe.com is GitHub Enterprise Cloud with data residency, and the hostname has no github label, so parsing returns null and the tool returns PullRequestUrlInvalidError: "This is not a recognised pull request URL. Pass repository and number instead."
   • A host that does contain github, such as github.acme.test, is already accepted. The same gap applies to any other GitHub host whose name does not contain github. Leaving /pull/ unrecognized on an arbitrary hostname looks intentional, because that path is not unique to GitHub.
   • Passing host, repository, and number skips the URL parser and builds the link directly, which is why your second call works. unlink_pull_request, watch_pull_request, and unwatch_pull_request share resolveTarget, so a *.ghe.com URL fails on those too.
   • The error text names repository and number, not host. When the thread's project remote is already that Enterprise host, repository and number are enough. On any other project, following the error can link the wrong host, or hit "This thread's project has no recognised remote. Pass host or url."
   • The runtime instructions still tell agents to call link_pull_request with the full PR URL, and the tool description's example is a github.com URL, so an agent on a *.ghe.com host fails the first call every time.
   • This is a different problem from the open GitHub Enterprise detection PRs (fix(server): detect GitHub Enterprise remotes that gh is signed in to #7959, fix(server): recognize authenticated GitHub Enterprise hosts #11059). Those cover gh auth discovery for custom remotes and do not change this URL parser.

   Likely fix area

   • Teach parseChangeRequestUrl / isHostOf to recognise *.ghe.com (and any other known GitHub Enterprise Cloud host shapes) the same way it already accepts hosts with a github DNS label.
   • Optionally improve the error text so it mentions host when URL parsing fails.
   • Optionally adjust the link_pull_request instructions / example so agents on non-github.com hosts know to pass host, repository, and number until URL parsing covers them.

   Until then, the working call is the one you already found: host, repository, and number.

   A maintainer will decide on the fix direction.
3. juliusmarminge

   added

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   and removed

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Oct 5, 2026