GITHUB_TOKEN cannot access private packages

Wow! This appeared in set up job section:

GITHUB_TOKEN Permissions
  Actions: write
  Checks: write
  Contents: write
  Deployments: write
  Issues: write
  Metadata: read
  OrganizationPackages: write
  Packages: write
  PullRequests: write
  RepositoryProjects: write
  SecurityEvents: write
  Statuses: write

Are there any news regarding this?

1 Like

I too have come across this hurdle. I have two private Java repositories, one has a Maven action that relies on the artefact deployed to the other repository’s GitHub Package Registry.

My workaround is as follows - Note: this is only good practice for single user private repositories as your Personal Access Tokens (PAT) should not be used by others.

I have added two secrets to my repository (the one dependant on the artefact of the other):


I generated the PAT using the following permissions only:
read:packages (Download packages from GitHub Package Registry)

Below is my action definition

name: Java CI

on: [push]

    runs-on: ubuntu-latest

      - uses: actions/checkout@v2
      - name: Set up JDK 11
        uses: actions/setup-java@v1
          java-version: 11
      - name: Cache Maven packages
        uses: actions/cache@v2
          path: ~/.m2
          key: ${{ runner.os }}-m2-${{ hashFiles('**/pom.xml') }}
          restore-keys: ${{ runner.os }}-m2
      - name: Build with Maven
        run: mvn --batch-mode --update-snapshots --activate-profiles github --settings settings.xml verify
          MAVEN_USERNAME: ${{ secrets.MAVEN_PKG_USERNAME }}
          MAVEN_PASSWORD: ${{ secrets.MAVEN_PKG_PAT }}

And my settings.xml (change USERNAME)

<settings xmlns="" xmlns:xsi="" xsi:schemaLocation="




This issue wasted so much of my time this week. Really would expect this to be fixed by now. Luckily for now I can work around it by (ab)using a PAT.

The PAT workaround works as long as you’re not using services such as Dependabot. Our Dependabot workflow is broken since the first of Mars due to this limitation.

1 Like

Similar to others here, just wasted time trying to move over to Github Packages only to realise I can’t (plus the Dependabot PAT thing meaning even that workaround wouldn’t work).

Is this on the roadmap? The last Staff reply here was in 2019.

We’ve got about a bunch of interconnected repos and this & the lack of org-level workflows (private actions etc) means we just can’t use a lot of the new Github features.

(Looks like the Dependabot PAT thing can be worked around by defining which secrets are ok to pass to Dependabot, but I’d rather avoid that if this is coming at any time)

1 Like

I am also interested in a soltution here. Currently we are also using PAT to read private organization packages.

It looks like the GITHUB_TOKEN permissions feature has been added: GitHub Actions: Control permissions for GITHUB_TOKEN | GitHub Changelog

but I don’t see anything about OrganizationPackages as this prior post seemed to indicate:

Also can’t find anything in the docs about it.

Looks like this is still an issue?

I haven’t investigated the new Control permissions, so I don’t know if that fixes the above problem or no. I’ve put it on the list of things to do.

In general, I have used a GitHub App and this action (GitHub - tibdex/github-app-token: Impersonate a GitHub App in a GitHub Action) to dynamically generate PATs when I need them, to decent effect.

It’s not solved. The new github token permission per-job settings is great, but it’s missing the organization level stuff still.

We’re publishing a maven package in another private repo, and depend on it in the project at hand. It seems impossible to setup maven so that github actions can build my project because of this dependency.

1 Like

You are correct that the GITHUB_TOKEN is only going to have permissions in the repo that triggered the workflow. That is for security reasons. You will have to generate a PAT to use to access information in another repository from that workflow.

So (just to confirm), there’s no planned support for org-level GITHUB_TOKEN’s before the 4 August deadline?


Github staff keep talking about this being a security thing, but the “solution” of using a PAT is just straight up worse for security than being able to use a properly scoped read-only token for org-wide packages.


@ethomson for more than 2 years this problem persists. There is still no valid solution for the problem, or a good enough workaround (PAT doesn’t work, since it provides access to also private packages, which is not secure).

Can you please provide a thorough response on why wasn’t it implemented, what is the official way of solving it and ETA for the solution. As the problem here is definitely not code-based, please also make transparent the reasons it wasn’t done yet.

I am sorry for being crass, but this is bullshit. there is no security problem with adding another permission called, say, organisation-packages, and giving it the permissions.
Creating a PAT is less secure: it provides access to ALL repositories the user has, not only to this organisation.

@mickeygousset as blunt as Igor was, he is correct. We’ve had to work around this issue for over a year and just because I’m not constantly bumping this thread, it doesn’t mean it’s still not an issue for our organization, I just feel that with all the feedback already provided, it seems futile.

The only secure workaround we know of is creating an additional github user account which only has access to the organization’s repositories and creating a PAT to provide access to them (and only them).

Creating these fake/shadow user accounts for this purpose not only is confusing, costs additional monthly license fees, but is also less secure as it’s another account that needs securing and maintaining.


Hey @yhaskell @danrivett: I always appreciate blunt feedback.

Have you tried creating a GitHub App, and requesting a token from that app? That eliminates the need for a service account, as mentioned by @danrivett. And yes, while that is still a PAT, it is a little more controlled.

Unfortunately, I don’t see anything on the public roadmap around this. And I don’t have insight into the technical debt/issues that might prohibit adding security permissions to the token.

I’m gonna take the link to this thread and toss it out internally and see if I can get some responses on why it is this way, any other options, and anything that might be coming. I’ll report back.

meh, it could be that GitHub App tokens also don’t work. I haven’t tried it yet. I’ll try and confirm that as well.

@yhaskell @danrivett

Ok, here is what I have learned that I feel I can say publicly. I will apologize in advance for any vagueness, but at this point its the best I can do. I’ve conversations with several people to understand the issue, the workarounds, and what is coming. Unfortunately, there isn’t much I can say, but let’s see if what I CAN say helps at all.

First off: Using a GitHub App to generate a token won’t work. The package permissions aren’t there to allow you to scope the GitHub App token. This is something the product team is aware of, however, I don’t have an ETA on when this might be fixed, and there isn’t anything on the public roadmap about it that I saw.

Which unfortunately leaves us with having to use a PAT to make this happen. The product team is aware that this is not ideal. I can’t say more about why it was done this way, or what would have to be done to fix it. You will have to trust me there are some technical reasons why, and that the product team is aware of the community’s concern. This is feedback we have heard from other customers as well, so I added this thread onto that feedback.

As with the GitHub App issue, there isn’t anything on the public roadmap around this yet. As soon as there is, I will come back and update this issue.


I was just about to comment the same thing! Using the OAuth gen token gets you: “This credential type is not supported for registry. Please use a Personal Access Token or GitHub Actions token instead.” Nice helpful error, at least :grin:

Aren’t the package permissions available though?

@arbourd They are, but they don’t seem to work. The product team is aware of that and looking into it.

1 Like