Repository navigation
Support GitHub App authentication with client credentials #1333
Description
Activity
GitHub MCP supports installation tokens, you can generate it following this doc: https://github.com/proxy/docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/generating-an-installation-access-token-for-a-github-app
You can use this token instead of PAT.
@almaleksia Does it support User access tokens?
I tried creating a device token for the app using my user and it didn't workYes, we support user access tokens. What do you mean by device token? At the end of the flow described here you should get the token that starts with
ghu_prefix.Can you describe step by step how you generate token and what error are you getting?
Can you have a look at #1649 it provides a secure url elicitation oauth flow including bring your own app, with client id and secret.
Right now it's experimental, but in hope it will be merged eventually.
GitHub MCP supports installation tokens, you can generate it following this doc: https://github.com/proxy/docs.github.com/en/apps/creating-github-apps/authenticating-with-a-github-app/generating-an-installation-access-token-for-a-github-app
You can use this token instead of PAT.
As per the docs, these tokens expire after an hour which makes it impractical?!
Reacted by Craig WeberThat's how app authentication flow works according to OAuth, you have long lived refresh tokens and short-lived access tokens. The client is responsible for requesting new tokens when old ones expire.
Reacted by Sam Morrow, Clicia Scarlet (Phan Duc) and Aamir AhmadTry this testing release of STDIO server with baked in oauth app that also supports bring your own app:
- added a commit that references this issue
on Apr 16, 2026 Any update on this. It will be great to have this functionality of GitHub App instead of using a PAT for the GitHub mcp
Reacted by Andre Elizondo and Krzysztof MagosaI've opened a pull request here: #2562
If the client supports refresh tokens properly then I don't know why it wouldn't work, I believe this to be a client gap primarily.
That said, I do want to merge my change, and I have seen the other other PR. 🙏
If the client supports refresh tokens properly then I don't know why it wouldn't work
I'm using Claude Agent SDK in a service that runs longer than an hour. We could implement token refresh on the client side but it's a lot easier if Github can do the token refresh on the MCP server side so not everyone has to implement this in its client.
I have now merged STDIO oauth. Please give it a look!
@SamMorrowDrums : I don't know whether I understood the oauth feature completely, but does this also work for server->server automations in a non-interactive environment, as was the root use case for this issue?
My situation: we use GitHub Copilot cloud agent and want to give the cloud agent access to more than just its own github repository. According to this Copilot docs page we have to customize the github mcp server configuration with a PAT with correct permissions.
BUT: Copilot cloud agent is used by many colleagues in a given repository, so ideally we want to use a "GitHub App" for authentication instead of a single colleague's PAT (as we do right now with a custom agent and a fine-granular PAT as agent secret). Problem is, the installation access token for GitHub apps are only valid for 1 hour and so don't fit for this use case. The new oauth feature does not seem to fit either as Copilot Cloud Agent runs in the background and is not tied to a single human user. How would you tackle this problem without creating a "service account user" in github and creating a PAT for it? Creating an extra user does not seem like a good solution when something like GitHub app authentication exists .Thanks for your help!
With merged version can use a GitHub App and will refresh the token. You'll still need to complete Oauth flow interactively to get a token. Device code is supported and if elicitation isn't supported device code is returned to model as last resort.
Does that cover your use case? If not I'd love to understand what else you need.
@herzogf we would still need to support PEM file to remove interactive requirement. That will require a follow up.
I reopened because it's fair to track that part. It's just that GitHub Apps are now supported with token refresh.
So it's only one outstanding part for this. I wanted user flows to work with priority, but I understand why you want this.
- added a commit that references this issue
on Jul 15, 2026
Currently, the server only supports authentication via Personal Access Tokens (PAT) or OAuth.
For organizations managing multiple integrations, GitHub Apps are preferred because they:
Add support for GitHub App authentication using:
This would allow the server to generate installation tokens programmatically instead of requiring PATs.
Alternative configuration:
{
"GITHUB_APP_ID": "123456",
"GITHUB_CLIENT_ID": "Iv1.abc123",
"GITHUB_PRIVATE_KEY_PATH": "/path/to/private-key.pem"
}
Is this on the roadmap?