Add html_url to list_issues results

[sawyer0x110]

Summary

list_issues previously returned html_url when it used the REST API response shape. After the tool moved to GraphQL, the minimal issue fragment no longer selected the issue web URL, so html_url was omitted from list_issues results.

This adds the GraphQL issue url field back to the list_issues response as html_url, aligning the issue list output with list_pull_requests, which already includes html_url for each returned item.

Including the web URL gives chat clients a stable, navigable link for each issue in the result.

Testing

• go test ./pkg/github -run 'Test_ListIssues|Test_ListIssues_FieldFilters|Test_ListIssues_IFC_InsidersMode|Test_LegacyListIssues'

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

This PR populates html_url for issues returned via GitHub GraphQL by selecting the url field in issue fragments and wiring it into the minimal issue representation.

Changes:

• Add url to IssueFragment and LegacyIssueFragment GraphQL selections.
• Map GraphQL url into MinimalIssue.HTMLURL.
• Update issue listing tests and expected GraphQL query strings to include url.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

File	Description
pkg/github/minimal_types.go	Maps fragment url into MinimalIssue.HTMLURL.
pkg/github/issues.go	Extends GraphQL fragments to select the url field.
pkg/github/issues_test.go	Updates fixtures, query expectations, and assertions for populated HTMLURL.

[SamMorrowDrums]

@sawyer0x110 I have not encountered agents that can't construct the URLs from the ID consistently.

Can you explain more? They are very token heavy for just adding a standard repo owner url around the issue number.

[sawyer0x110]

@sawyer0x110 I have not encountered agents that can't construct the URLs from the ID consistently.

Can you explain more? They are very token heavy for just adding a standard repo owner url around the issue number.

Hi @SamMorrowDrums

That makes sense, and I agree agents can often construct the common github.com URL from {owner}/{repo} and the issue number.

The case I was trying to cover is less about whether the model can synthesize the URL, and more about keeping the read tools consistent. Other issue/PR surfaces already return a canonical web URL (issue_read, search_issues, and list_pull_requests), so list_issues feels like the odd one out after the REST-to-GraphQL migration. It used to include html_url in the REST response shape, but the GraphQL fragment no longer selects url.

Having the GraphQL url also avoids clients or agents having to reconstruct links from assumptions about the host/path format, which matters for non official deployments or clients that turn tool output fields into navigable links/citations without model-side URL synthesis.

I understand the token concern. It does add one URL per issue. My read is that the cost is relatively small for modern agent flows that use progressive disclosure and load tools/results on demand, while the consistency and canonical-link benefits are useful.