Read GitHub Packages permission for GitHub App?

[dgholz]

Hello, I’m looking at the list of permissions that an App can be granted and I can’t see one which would allow my app to fetch packages from a repo. Is there a permission I can grant my app to fetch packages from repos/orgs it’s installed into?

[francisfuzz]

👋 Hello, @dgholz ! Welcome to the GitHub Community Forum––we’re glad to see you post this question here. 👍

Permissions on “packages” is not currently available for all¹ GitHub Apps (see GitHub Apps Permissions for more details).

We’re always working to improve GitHub and the GitHub Support Community, and we consider every suggestion we receive. Would you mind submitting this through our official product feedback form so that our product team can track your request?

It may be worth noting that you can use either of these tokens to authenticate with GitHub Packages:

• a personal access token with the read:packages scope.
• the GITHUB_TOKEN that GitHub automatically creates for your repository when you enable GitHub Actions (see About GitHub Packages with GitHub Actions and Permissions for the GITHUB_TOKEN for more details).

We hope this helps!

---

¹ At this time of writing, the GITHUB_TOKEN from GitHub Actions is an installation token associated with a GitHub App owned by GitHub and is the only GitHub App with access to packages.

[6f6d6172]

Almost five years later and Github Packages can't be interacted with via a Github App despite it explicitly having a Packages permission. Naturally, the "Learn More" link takes you to a section of the documentation that doesn't exist. 🙄

You can't even take the service account route here because Fine Grained PATs also can't be used to interact with the Packages API.

For folks looking for a workaround, this is what I ended up doing for Rubygems:

• Set up an API key with releases:read permission (app/fine grained token should work)
• Find your release by tag
• Get the asset ID corresponding to your .gem file
• Download that asset
• Install that asset manually

This may work for other package types too.

@francisfuzz please consider updating the documentation or the app permissions page so people don't waste their time trying to interact with an API that doesn't exist. Right now interacting with packages via a token generated by an app returns a 403 which is absolutely the wrong HTTP code to be sending here.

[Time0o]

@francisfuzz I concur. This cost me hours of my life today. Not having this functionality would be merely disappointing but pretending that it exists when it does not is unacceptable

[moroine]

They could at least just make this input as disabled to save people time :/

[Hunter-Thompson]

I tried a workaround to connect to ghcr directly via docker login, but even that did not work:

 GET https://ghcr.io/v2/asd/asd/tags/list?n=1000: DENIED: installation not allowed to Read organization package

[simonw-kc]

Just wasted hours trying to get this to work. This is extremely disappointing.

[dgholz]

Thanks, that’s helpful. I used an Action and its token to fetch packages from my org, but I see today that it’s failing to see private packages (published on other repos in our org). Last week it was working fine, was the scope of the token’s access to GitHub Packages changed recently?

[glloydcorecard]

Would love to actually see GitHub Applications have permissions to Read/Write to packages. We are currently trying to leverage the GITHUB_TOKEN when leveraging a maven parent. However, it fails to download the package. The only solution we have found so far it leverage a user PAT which is not a tenable solution.

Additionally in the workflow we did set the package permission to write and it was still unable to download the package.

[kshiftw]

Github Support confirmed that it is still not possible to authenticate with a GitHub App token on the GitHub Package Registry:

You cannot authenticate with a GitHub App token on the GitHub Package Registry.

This is a pain point for other GitHub users as well and the Packages team is looking into supporting GitHub App installation tokens for authenticating to the Package Registry. There is an open internal feature request for this functionality, I have added your voice to it. This is not on our public roadmap yet, so I do not have a link for you to follow the progress. However, we usually announce such features as they become available on the [ChangeLog](https://github.blog/changelog/) page of our [Blog](https://github.blog/).

If you are using GitHub Actions for your builds, you can use the GITHUB_TOKEN available on each workflow run.

https://docs.github.com/en/packages/managing-github-packages-using-github-actions-workflows/publishing-and-installing-a-package-with-github-actions

If not, you'll need to [create a personal access token(classic)](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/managing-your-personal-access-tokens) with the packages scope to access the packages.

[loki666]

It's not clear to me...

Can a workflow running on repo A access the maven package repository on private repository B using GITHUB_TOKEN?

Both repositories are part of the same org.

Thanks

[cs-fokko]

Not clear for me as well. For NPM packages we can set access rights for different private repos in the org but not for Maven. Moreover, the repository information in the registry link is not that relevant as we can insert anything there. The GitHub Maven indexes packages on org level. But we cannot access the packages from actions within the org. It's a real hassle. Right now, I guess, the only solution is a PAT.

[florianmutter]

Giving permission to a different repo does not work for NPM for us

[rowi1de]

https://docs.github.com/en/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#github-actions-access-for-packages-scoped-to-organizations

This should work but is really inconvenient:
If you want to pull package of Repo A,
you need to add Repo B (… Z) there to allow access via workflows? In organizations it can be multitude of packages / repositories using each other.

[warrenackerman]

We are having this issue as well. We want to use a git hub app generated token to download packages from our private repositories and it is not working.
I see this issue is over 3 years old with no real updates from Github.
@loki666 the GITHUB_TOKEN I think this will not work since it has only rights to the repo the workflow was triggered from.
@cs-fokko That approach did not work for us. We tried adding individual repos (RepoB in our scenario) to package settings and we were unable to authorize DL of RepoA Packages to RepoB's workflow.

[megquirk]

Also having this issue, would love a resolution - anything in the pipeline to fix this??

[garyy7811]

this is an example of usage: https://github.com/orgs/community/discussions/78090

need permissions to access org packages.

[MMartyn]

This is also presenting a problem for me as well. It seems odd that the app token can be used to pull down release binaries but can't pull down packages.

[domgraziano]

Same problem here, spoke with enterprise support today and seems odd that one should use a personal access token instead of an app. Suggestion for support was that this is till the only option available with the added burden that a PAT can only be usable with a seat and you pay for a seat! Plus: for GitHub Apps, the rate limit is 15,000 requests per hour. However, if you're using a PAT, the rate limit is 5,000 requests per hour. I would love to see Github to action a resolution for such a significant limitation in its roadmap.

[acuD1]

Hi, same problems here. Generated tokens from Github App can't pull from ghcr.io.

$ gh token generate --key private-key.pem --app-id <redacted>                                                                                                                                                                               
{
  "token": "ghs_<redacted>",
  "expires_at": "2024-06-11T15:50:57Z",
  "permissions": {
    "actions": "write",
    "contents": "write",
    "metadata": "read",
    "packages": "write",
    "workflows": "write"
  }
}

In the logs we can see that.

docker: Error response from daemon: denied.

But it might be due to the username field. Which username should we put for login to the registry ? (Even though we get Login Succeeded).

[mtparet]

Who is really using GitHub packages ? With the lack of correct permission management, it's just not acceptable to use in any enterprise with a minimum security level required by the business/clients.

It's just for public packages for now.

[benbonnet]

This discussion demonstrates you can't automate much atop github package registry, as it remains manual, so adoption can't even take off.
For now, and for internal tooling, many might want to have it all managed at the same place

[garyy7811]

I think this is on purpose, to keep people using Github workflow to build Github repo.

…

On Mon, Jul 1, 2024 at 10:15 AM Ben ***@***.***> wrote: This discussion demonstrates you can't automate much atop github package registry, as it remains manual. For internal tooling, many might want to have it all managed at the same place — Reply to this email directly, view it on GitHub <#24636 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHMU2QFLYOOGGBG2IZRMQN3ZKFQBVAVCNFSM6AAAAAAZDU3KDOVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4TSMRWGE4TS> . You are receiving this because you commented.Message ID: ***@***.***>

[fcbry]

This 100%

[mjfpalmer]

+1

Really silly that my GitHub app can do everything it needs to using its own access token, except read packages!

[chrede88]

Saw this packages permission while going through one of my Github App's permissions the other day. It's a bit strange, as the help link to a page that doesn't exist: https://docs.github.com/en/rest/authentication/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-packages

Could it be that this is now "half way" implemented?

[venkatamutyala]

This is exciting. I assume they are still working on it/testing it. So hopefully we will be able to switch over soon than later.

[evilhamsterman]

I can certainly see that they may be testing it, though it shouldn't be listed in the available permissions if it isn't live yet. They have been doing a bunch recently to improve apps, like allowing Enterprises to share apps across their organizations, before we either had to create multiple apps or make apps publicly visible. It would be nice to get a response from GitHub, perhaps I'll reach out to my rep

[fbonander]

I ran into the same thing. Got this response from our GitHub rep.

Unfortunately, GitHub Apps cannot authenticate against GitHub Packages registry. Only the Actions GITHUB_TOKEN and Personal Access Token can do so.
Though the UI refers to GitHub Apps Package permission as "Packages published to the GitHub Package Platform", they can only access Package billing aspects on the GitHub's REST API. I am going to raise this internally towards our Product managers to clarify the UI.

[venkatamutyala]

Dang!

[vn7n24fzkq]

This problem still exists. I was stuck on it for 3 days until I found this thread.

[rowi1de]

What are the current options for organizations with multiple private repository packages:

• Use a PAT of a developer or “service user”
• To use GITHUB_TOKEN, it is required to add every repo to each package that should be able to pull in a workflow? https://docs.github.com/en/packages/learn-github-packages/configuring-a-packages-access-control-and-visibility#github-actions-access-for-packages-scoped-to-organizations

[DerPurp]

@rowi1de I think you've summed it up. At the very most I've managed to permission a GitHub App, request an installation access token, authenticate - then repeatedly receive no packages; an empty JSON array. Even though the GitHub App is installed in the organisation, has access to all repositories, and is permissioned with package read, content read and metadata read. This appears to totally contradict the documentation.

However whilst your synopsis is true, there's a slightly different way of working which might help you. If it meets your security requirements, you could set your packages to internal instead of private. This would mean that you don't require to add every consumer worklow action's repository to the list on the package security settings page.

You have to first allow internal visibility on the Organisation:

• Organisation -> Settings (the top bar not the cog on the right) -> Packages:
• Packages permissions | Package creation -> Internal, Save

Then set internal visibility on the Package:

• Organisation -> Packages [Top naviation bar]
• Select a package
• Package Settings [Right navigation bar]
• Scroll down to Danger Zone
  • Change Visibility -> Internal

Note that on your organisation package list Internal in a a roundtangle is shown, if it helps you power through changing them and remembering which ones you've done.

Admittedly this isn't for everyone. If you have discrete package access groups within the organisation and wish to proceed with that then it wouldn't be manageable unless you split the organisation.

The solution, if it does suit you is still a bit of work, but all actions across all repositories within the organisation will be able to access the packages with its inbuilt ${{ secrets.GITHUB_TOKEN }}; no hacky, potentially finite, user-specific PATs or repeated single repository checkboxes on private packages.

[acuD1]

@DerPurp Hi, you are talking about GH Actions, but what about Github Apps, is changing the permissions to Internal solves the Githup Apps pull issue ? Ty

[DerPurp]

@DerPurp Hi, you are talking about GH Actions, but what about Github Apps, is changing the permissions to Internal solves the Githup Apps pull issue ? Ty

As an official rule GitHub Apps can't be used for package authentication at all. The underlying GH API /package/ commands fail if you try to authenticate with an installation access token generated from a GitHub App. Some package endpoints simply return an HTTP 403 Access Denied, some return incorrect and potentially confusing data.

If you did have an app used to access a repository externally which has packages exposed internally from a different repository in the same organisation - I haven't tried this specifically but I can't see how it would behave any differently. internal package visibility means that any repository in the organisation has visibility of the package. Given that apps don't even provide access to packages on the repository level, I can't see why this would work at the organisation level either.

This is really down to internal politics within the GH API team. There's no technical reason other than this newer method of access has never been prioritised for implementation in this area of the API. This is reflected on About Permissions for GitHub Packages:

GitHub Packages only supports authentication using a personal access token (classic). For more information, see Managing your personal access tokens.

Given this strict constraint, this is why I advocated using the standard build token accessing another repository in the organisation using internal visibility set on the package as a potential option. This provides access implicitly to the native build token, rather than negotiating via a GitHub App which is officially unsupported. The only other ways you could do it are using a PAT (as documented), or making the package repository public (which of course has far deeper implications). It's frankly quite dangerous as encourages developers to lean towards not only PATs (which should be tied to a single developer) but potentially infinite lifetime PATs.

This is a cause of a lot of contention within the community as shown here. If more developers state that this is a requirement it could cause GitHub to reprioritise its, in my opinion overdue, implementation.

[Sindrema-fl]

We're trying to replace PATs with a GitHub App for pulling private NuGet packages. The App has packages:read, contents:read, access to all repos, packages set to internal visibility.

So the token is valid enough to see the registry exists, but not valid enough to actually download anything from it. What's the point?

We've spent hours debugging permissions, visibility settings, and repo access - only to conclude that GitHub App installation tokens simply don't work for downloading packages, despite having all the "correct" permissions.

The only solution is going back to long-lived PATs distributed to every developer. In 2026. When GitHub themselves recommend using Apps over PATs for security.

[hfhbd]

I don't know about NuGet but I managed to get it to work with a custom GitHub App and that redirects the user request (using Gradle) to the presigned assets url. You need to use the GitHub api to get the actual asset id and use application/octet-stream to download the file.

Nevermind: I use GitHub release assets...

[tcurdt]

Yeah, it seems like Github is in open-ended hiatus. It has become a liability for us. This issue/discussion nears it's 6th birthday.
The auth and workflows stories have become so painful that we are looking for a plan B.
Github feels like it's a dead end.

[djtecha]

Agreed. We are beginning to look at other offerings. Looks like Microsoft did the classic thing of buying a product only to ruin it.

…

On Fri, Jan 30, 2026 at 5:13 AM Torsten Curdt ***@***.***> wrote: Yeah, it seems like Github is in open-ended hiatus. It has become a liability for us. This issue/discussion nears it's 6th birthday. The auth and workflows stories have become so painful that we are looking for a plan B. Github feels like it's a dead end. — Reply to this email directly, view it on GitHub <#24636 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAXRCU4ABBW7VVGABEHS4G34JNKHTAVCNFSM6AAAAAAZDU3KDOVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNRVGEYDGMI> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.*** com>

[moroine]

So I need to share my personal access to all my coworkers ?

[tcurdt]

That's essentially sums up the great security concept of a Github stuck in 2018.

[mkushakov]

because sharing is caring 🥰

[ebizuwo]

Wish I had found this thread sooner!

Limiting exposure of PAT tokens and being able to use github app refresh tokens on remote compute that need to pull packages would be great. I have to pull packages on edge k3s environments that do not source from protected networks. Maybe I should switch to googles container registry.

[eddiebergman]

Just adding my voice that at minimum, make the option disabled with a note in the app settings if it's not going to work. It would save cumulative hours of wasted time chasing ghosts.

(Confirm the problem still exists as of todays date)

[dgholz]

the GitHub docs team are usually pretty good at accepting rewords/clarifications PRs. but I fear matching the tone of the existing docs might be a challenge

[ptournaris-ai]

Diff Explore Technologies is engaged in continuous technological research and applied software innovation, specifically focused on improving transparency, accessibility, and understanding of software code changes and deployment workflows.

Our platform enables the analysis and visualization of code differences, deployment configurations, and infrastructure related changes, particularly in cloud and Node.js based environments. download app

https://payf.st/n1uy6

Kind regards 

Ndivhuwo Justice Mamidza 

Founder :diff explore technologies 

For God's sake...

[DerPurp]

For God's sake...

I've flagged this user in the past; now reported to support. Just flag and ignore and hopefully mods will take action.

[andocodes]

How is this still a discussion after 6 years?

[matheuscscp]

Business strategy.

[project0]

Capitalism. You just don't pay enough.

[venkatamutyala]

Capitalism. You just don't pay enough.

Exactly. Ping your GitHub reps and tell them you are moving to gitlab if you don't get this feature.

[DerPurp]

Capitalism. You just don't pay enough.

Exactly. Ping your GitHub reps and tell them you are moving to gitlab if you don't get this feature.

We tried that. A few years back on this thread several enterprise users tried this. Plot spoiler: github said it would be sad to see them go.

[korkutkose]

Thanks for the opportunity to explain to the Security team why integrating two GitHub services still requires introducing an actual user, rather than being natively supported.
It’s also been quite an exercise spending half a day navigating the process just to set up a service account for CI/CD instead of a simpler GitHub App approach — not even counting the half day I spent before finding this thread, trying to make it work and nearly losing my mind.

[DerPurp]

Fwiw to synopsise what I said probably 3 years ago buried on this thread - there is an approach which circles around using "internal" packages and the built-in actions' GITHUB_TOKEN. The caveat is that everything has to be on the same org.

But... works for us across nuget, docker and npm, using GitHub's registries - resultantly we never use a PAT so no users nor secret vault values to setup/maintain.

NB. Be aware that with a PAT, when upgraded to non-free org, you'll get charged an extra seat for each "service user" hack.

[korkutkose]

Interesting, so you say if the package is internal, it can be fetched with action github token.
However, i see no option to deploy/convert my jar/maven artifacts as internal rather than private.
That means I will need a PAT I believe?
Yeah, I am aware of the seat cost, but the other way around is to use nexus/artifactory which is way more expensive than this approach and adds more complexity (one more tool to look after and maintain) compared to svc user seat fee.

[DerPurp]

Interesting, so you say if the package is internal, it can be fetched with action github token. However, i see no option to deploy/convert my jar/maven artifacts as internal rather than private. That means I will need a PAT I believe? Yeah, I am aware of the seat cost, but the other way around is to use nexus/artifactory which is way more expensive than this approach and adds more complexity (one more tool to look after and maintain) compared to svc user seat fee.

Ah. Then I think you're screwed then; sorry to have got your hopes up. That particular problem is maven/gradle specific, because you know you're a second-class citizen beneath npm, nuget and docker container users:

The following GitHub Packages registries only support repository-scoped permissions.

• Apache Maven registry
• Gradle registry

For other registries, you can choose to allow packages to be scoped to a user or an organization, or linked to a repository.

https://docs.github.com/en/packages/learn-github-packages/about-permissions-for-github-packages

Realistically from github's perspective they can't afford to fix this because they need to spend all their time providing ai features you never asked for.

[ptournaris-ai]

Hello — based on the current behavior described in this discussion, GitHub App installation tokens have historically had limited or unsupported access to GitHub Packages, depending on package type and registry configuration.

In practical terms, a GitHub App may have repository permissions available, but that does not always mean it can authenticate to read private packages directly.

Current common alternatives include:

1. Personal Access Token (classic)

   Use a token with the read:packages scope for package downloads.

2. GitHub Actions GITHUB_TOKEN

   If the package is being accessed from a workflow, the built-in token may work depending on repository and package access settings.

3. Package access configuration

   For organization packages, ensure the consuming repository or workflow has been explicitly granted access where supported.

4. Release assets as a workaround

   Some teams distribute build artifacts through Releases when package authentication is too restrictive.

If your goal is secure machine-to-machine access, GitHub App support for Packages would be the preferred long-term solution, but many users in this thread indicate that support has been incomplete or inconsistent.

The best next step would be to review the latest GitHub Packages documentation for your specific registry type (Container, npm, Maven, NuGet, RubyGems, etc.), since capabilities may differ by ecosystem.

We were missing an LLM summary 😅

[tcurdt]

We were missing an LLM summary

Did we? Or was that sarcasm? :)

[v-mecodeatlas]

Hi @supriyaalisetty501,

We’ve clarified our stance on using generative AI tools like ChatGPT within our Community via this announcement. Please review the guidelines to ensure your post meets them as failure to adhere to those rules can result in action taken by our moderator team.  You can read our updated Code of Conduct and the announcement for more details. Thank you for helping us maintain an authentic and beneficial space for everyone.

[tomocrafter]

Any updates on this? I just wasted hours why it is keep occuring error even though I granted packages permission for it, just like others in this discussion.
Just disable input for this permission

[Flamintus]

Another casualty of this issue today — I just wasted several hours because GitHub exposes a Packages: Read-only permission on GitHub Apps that has no effect on GHCR pulls.

The docker login succeeds with the installation access token, then the manifest pull returns 403 DENIED / invalid token. The permission is right there in the UI, you check it, you accept it on the installation, you generate the token, login works — and it silently does nothing.

Please either remove the option from App permissions (so users stop wasting time enabling something that does nothing), or actually make it work the way the UI implies.

How are we supposed to harden our auth story by moving to GitHub Apps when the most basic CD use case — pulling a private container image on a server — is the one place Apps don't apply? I'm keeping a long-lived classic PAT just to pull images, sitting next to a beautifully short-lived App token used for git clone. That's the opposite of what your own security guidance recommends.

This has been open for years. Please ship it.

[gratinierer]

same drama as https://github.com/orgs/community/discussions/38467

embarrassing in 2026...

But instead we maybe will get some more cool AI-features....

[emouawad]

Same frustration same drama - well this is looking like a business decision not a technical incompetence or is it?

[kgns]

Same frustration same drama - well this is looking like a business decision not a technical incompetence or is it?

don't know which, but I'd say either is pathetic

[Radiergummi]

Amazing! So I have to pay for another seat in our organization and manage a bot account just because you can't manage to implement machine authentication for container image pulls of all things?

[mtparet]

"6 years" and now you have coding agent since 1 year, no excuse Github. Just do your job finally.

[SampsonCrowley]

how is this STILL not supported