You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Repository resource completions silently turn GitHub API failures into an empty successful result for branches, tags, and commit SHAs.
completeBranch, completeTag, and completeSHA all discard the error returned by the corresponding go-github call. If the API returns a 403, 404, rate-limit response, or a transport error, the MCP client receives a completion response with no values instead of an error. From the client side this looks exactly like the repository has no branches, tags, or commits, which makes authentication and access problems difficult to diagnose.
Affected version
I reproduced this on v2.0.3 and current main (f385262).
Steps to reproduce the behavior
I used the repository's existing mock HTTP client to return a 403 from the branches endpoint, then called completeBranch:
The result is an empty values slice and a nil error. The same thing happens in completeSHA and completeTag because those functions also assign the API error to _.
Expected vs actual behavior
I would expect the completion request to return the GitHub API error, as the repository and pull-request completion paths already do.
Instead, the error is lost and the handler reports a successful empty completion (values: [], total: 0, hasMore: false). Propagating the errors from ListBranches, ListCommits, and ListTags should preserve the useful status and message for the MCP client.
Activity