How to configure the OAuth for GHE.com?

[derkoe]

We have GitHub Enterprise with data residency and want to use the GH MCP with OAuth.

How do we need to configure the GitHub App (especially permissions) so that this works.

Currently, I get errors when accessing anything but "get_me". Getting my profile works and answers with the correct data.

When accessing other stuff I get errors (mostly 404) - for example when calling "list_pull_requests":

GET https://api.xxx.ghe.com/api/v3/repos/my-user/test/pulls?page=1&per_page=30: 404 Not Found []

In the GitHub app I have set the following permissions:

• Repository
  • Metadata: read-only
  • Pull-requests: read-only
  • Issues: read-only
  • Contents: read-only
  • Administration: read-only

In the oauth scope I have set: "repo read:org read:user"

Any idea how to fix this issue? How do you have to setup the OAuth flow and the GitHub App to make this work?

[rakeshutekar]

The get_me works / everything else 404s pattern is diagnostic, and it points away from permissions.

Why 404 and not 403

get_me calls GET /user, which is a user-scoped endpoint — it only needs a valid user token, and no app installation is involved. list_pull_requests calls GET /repos/{owner}/{repo}/pulls, which is installation-scoped.

For a GitHub App, a repository that isn't covered by the installation is reported as 404 Not Found, not 403 Forbidden. That's deliberate — a 403 would leak the existence of private repositories to an app that has no access to them. So a 404 here almost always means "this repo is not in the installation", not "this permission is missing".

Things to check, in order:

1. Is the App installed on the account that owns my-user/test? An App installed on your org is a separate installation from one installed on a personal account. my-user/test looks like a user-owned repo, so an org-level installation won't cover it.
2. Is the installation set to "All repositories", or "Only select repositories"? If the latter, test has to be explicitly added. This is the single most common cause of exactly this symptom.
3. Did the user authorize the app? For user-to-server OAuth, the acting user must also have access to the repo. Effective access is the intersection of the app's permissions, the installation's repo scope, and the user's own access.

You can confirm all of this directly:

# what installations does this token see?
curl -H "Authorization: Bearer $TOKEN" https://api.xxx.ghe.com/user/installations

# which repos are in that installation?
curl -H "Authorization: Bearer $TOKEN" https://api.xxx.ghe.com/user/installations/<id>/repositories

If my-user/test isn't in that second list, that's your answer, and no permission change will fix it.

On the OAuth scopes

repo read:org read:user are OAuth App scopes. GitHub Apps don't use them — access is governed by the App's declared permissions plus the installation. If you're going through the GitHub App user-authorization flow, those scope values are ignored, so they're worth removing to avoid confusion about where access is actually coming from. The permissions you listed (Metadata, Pull requests, Issues, Contents — all read) are correct for list_pull_requests.

Note that Metadata: read-only is mandatory for almost every repo endpoint; you have it, but it's the one people most often miss.

Secondly — that URL looks malformed

GET https://api.xxx.ghe.com/api/v3/repos/my-user/test/pulls

That combines two host styles that the server treats as mutually exclusive. From pkg/utils/api.go:

if u.Hostname() == "ghe.com" || strings.HasSuffix(u.Hostname(), ".ghe.com") {
    return newGHECHost(s)
}
return newGHESHost(s)

• newGHECHost builds https://api.<hostname>/ — no /api/v3 segment.
• newGHESHost builds https://<hostname>/api/v3/ — no api. prefix.

Your URL has both, which means the host got routed down the GHES path with api. already baked into the configured hostname. Two things to verify:

1. GITHUB_HOST should be the tenant host, not the API host — https://xxx.ghe.com, not https://api.xxx.ghe.com. The api. prefix is added for you by newGHECHost.
2. Use a recent server version. The .ghe.com → GHEC branch above is what routes data-residency tenants correctly; on a build without it, every non-dotcom host falls through to newGHESHost and gets /api/v3 appended.

If get_me genuinely returns correct data against that URL, then your tenant is tolerating the /api/v3 prefix and the installation-scope issue above is the real blocker. Fixing GITHUB_HOST is still worth doing, because the GraphQL, uploads, and raw URLs are derived the same way and will not all be so forgiving:

gqlURL    = https://api.<host>/graphql     // GHEC
uploadURL = https://uploads.<host>/
rawURL    = https://raw.<host>/

So the sequence I'd follow: fix GITHUB_HOST to https://xxx.ghe.com, upgrade the server, then re-check the installation's repository list. The second is very likely what's producing the 404s.