GITHUB_TOKEN does not have permissions to read other private repos in the same organization

[jabalsad]

Select Topic Area

Product Feedback

Body

Hello,

It appears that the GITHUB_TOKEN secret that is available in Github Actions environments does not have the ability to be configured to read private repositories within the same organization. The only workaround right now is to create permissive PATs that allow this. It seems strange that a PAT is required to read a repository, but not a private package in the github package repository.

Should this be a feature request on the permissions available to GITHUB_TOKEN?

[ilmax]

I also second this, it would be nice if we can define in the permissions configuration section which other repos that belongs to the same organization the GITHUB_TOKEN has access to.

The use case for me is consuming shared terraform modules defined in a standalone repo, e.g. 1 repo for shared infra, several repos consuming the shared infra. As of now to get terraform init work correctly we have to go through several unpleasant hops like creating a PAT and updating git config.
It would be nice if we could get this working OOB with a simple permissions change in the workflow and probably a flag on a repo level to allow actions running from other repos to interact with it

[qoomon]

probably the closest solution => https://github.com/orgs/community/discussions/46566#discussioncomment-9638833

[dennysis]

It not working properly , it still has an error

[landsman]

we need official solution, not 3rd-party

[asbjornu]

+1 from me as well. My use case are:

1. Having a central key repository which is accessed by other repositories' GitHub Actions during builds and releases to Apple TestFlight and App Store (for use with Fastlane specifically).
2. Private repositories as Git submodules. The workaround of creating a GitHub App which has read-access to the required repositories as proposed in Support private repositories and private submodules actions/checkout#287 (comment) works, but feels like a massive hack.

[qoomon]

Maybe my action could be useful for your use case https://github.com/qoomon/actions--access-token

[Patrick1411]

Hi @qoomon, i am using your action "https://github.com/qoomon/actions--access-token", but i got some error, could u help me fix that

[qoomon]

@Patrick1411 sure, just open an issue at https://github.com/qoomon/actions--access-token and we'll figuring it out

[prabhat-sc]

+1 looks like there is no option other than defining a an organization level secret as a token.

[probitdavid]

It would be nice to have a setting that is all private action runners can access all packages in this org.
This would remove the need for PAT as a secret and also make dependabot updates MUCH simpler as there would be no need to add tokens to that world too

[babu-izhan-5001312]

Hi, I am working on adding dependabot in my repos, but the github actions are failing as it does not have access to other private repos. How are you currently giving the github action that was triggered by dependabot access to private repos ?

[KT-Anja]

I have just been able to solve the problem in our repo. There is an option in the package settings to give certain repositories within the same organization access from the Github Actions. https://github.com/orgs/XXorgaXX/packages/npm/XXrepoXX/settings.

Additionally, I had to add the registry URL in the setup-node step:

uses: actions/setup-node@v3
    with:
        registry-url: https://npm.pkg.github.com 
        scope: "@XYZ"

[giner]

This only works for GitHub Packages which belong to other repositories but not other repositories themselves. Also it doesn't work for Maven repositories (not related to question in the topic though).

[wlandau]

It appears that the GITHUB_TOKEN secret that is available in Github Actions environments does not have the ability to be configured to read private repositories within the same organization. The only workaround right now is to create permissive PATs that allow this. It seems strange that a PAT is required to read a repository, but not a private package in the github package repository.

My colleagues and I maintain internal R packages in GitHub repos (not the same "GitHub Packages", which we don't use). We want to have an ecosystem of R packages that depend on one another, and the checks in https://github.com/r-lib/actions rely on the ability of every internal R package to be installed from every internal GitHub Actions repo. To make this work, every user needs to create their own personal access token, which is painful for experienced developers and utterly confusing for new users.

@github, would you please allow GITHUB_TOKEN to have read access to internal repositories within the same organization? This is absolutely critical for what so many of us are trying to do (related: https://github.com/orgs/community/discussions/46566), and it will be more secure than PATs because GITHUB_TOKEN is a temporary one-time token.

[wlandau]

Could be a while before I hear back, but let's remember here that GITHUB_TOKEN would be much more secure than a custom org-level token because the former is short-lived and gets a new value for every workflow run.

[MC-Dave]

I second this. It would not only be convenient to have, but it would also allow for a more secure development and deployment workflow.

For example, python's pip allows for ENV variable expansion in requirements.txt files. In order to install from a private github repo, an access token must be provided in the requirements.txt file in the form of an ENV variable. This flow would work seamlessly in github actions with the GITHUB_TOKEN IFF one could give org-level read permissions to said token.

[landsman]

Yes! Critical thing to have and GitHub do not care at all...

[jaredweinfurtner]

An update: my organization somehow created an org-level secret that members can successfully use as if it were a PAT for the purpose of cloning other internal repositories inside GitHub Actions workflows. I will try to find out how they did that and then report back.

@wlandau DId you get an answer?

[mlebkowski]

I know of two ways:

1. Use a deploy key. As far as I know, one deploy key can be assigned only to a single repository, so that wouldn’t be one secret
2. For purposes other than just clonning, one can create a github application.

• One should create & configure a new application, with a special focus on the permissions section. The token you’ll get in the end will have the exact permissions you selected here.
• Then you install the application on your organization. This might require admin privileges or an admin approval. That will get you an installation ID
• Next thing is to generate and fetch a private key for that app. This is the secret part that will allow you to create an JWT token that can be exchanged for an actual access token
• You can use this script (I might have made some typos when creating the gist) to produce the access token: https://gist.github.com/mlebkowski/b872e002d4dd76b53c057054cf945467

[vgpastor]

Same issue when i try to access terraform modules inside an action, terraform init can't access private repos in the same organization.

Please @github any secure solution?

[ghost]

Did you try to use a solution with GitHub Apps from comment above?

[landsman]

Yes pls!

[alona-shevliakova]

+1

[mvarchdev]

+1!

[nassorh]

+1

[cvicenti]

+1, we run a git clone of another repo within the same org as part of one of our workflows and this would be way better than using a user-tied PAT

[dspv]

Have the same issue. Tried with another org and it works good. Magic

[earlye]

Yup. Necessary to avoid having long-lived PATs as secrets.

[danielbressan]

+1 would love to have this

[MaxAnderson95]

The best method in my opinion to this problem is octo-sts. You can even self-host if you're more risk averse.

But as others have stated, only the GITHUB_TOKEN or a PAT can be used to read/write GitHub packages so this does not solve this use case. Octo-sts uses a GitHub app under the hood to generate app tokens on the fly. These don't work with packages still for some reason.

[qoomon]

Basically the same approach as https://github.com/qoomon/actions--access-token

[fmacedoo]

+1

[AimoreRRD]

Has this been resolved? If not, can github provide a better work around that using PAT?

[milesflo-bd]

+1

[iam-jawad]

+1

[jed-exotic]

For all +1'ing this, consider using a GitHub App to securely retrieve your private repos -

1. Issue a GitHub App, install it/configure permissions so it can perform contents: read
2. Obtain a GitHub App token using https://github.com/actions/create-github-app-token
3. Leverage the output of that GitHub App Token to access the private repository

[qoomon]

to get rid of dealing with long living credentials use https://github.com/qoomon/actions--access-token instead

[qoomon]

@jaredweinfurtner why the down vote?

[karl-petter]

Our use-case is that within the Organisation in out GitHub Enterprise with data residency we have setup that all developers can read all INTERNAL repos because we want to establish an internal open-source culture. In that context it is very natural to expect every workflow can checkout any of the internal repos (of course not private ones). Now it seems we need to provide all developers with an internal GitHub app that is allowed to do that that then all workflows that want to do this needs to use.

[sdasgupta-spectra]

+1

[shanewrn54-max]

GitHub Actions can’t read private repos in the same org. From my side, that makes total sense why it causes headaches if you’re trying to share code or modules privately you end up needing to create a personal access token instead. It makes me wonder why GitHub hasn’t made that smoother for orgs yet.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[nebuk89]

I don't think I have ever put a comment on this one, so adding one :)

We are going to investigate this in the new calendar year (going into 2026). Thanks for the patience on this one, Pats and Apps are not enough and we will be looking at how to achieve this with the GitHub token.

Keep providing feedback <3 and thank you for all engaging for so long

[wherka-ama]

Hello,
if anyone here is still interested in this topic I might have some good news.

I've been working on a GitHub CLI extension that solves a common pain point: managing Git authentication across multiple organizations.

Key features:

• 🔐 GitHub App authentication - No more long-lived PATs for CI/CD
• 🔀 Pattern-based routing - Different credentials for different repos/orgs (technically they are not really patterns, more like a hierarchy based approach - org or org/repo)
• 🔑 PAT support - Mix GitHub Apps with PATs when needed
• 🏢 Multi-org friendly - Works seamlessly with submodules across orgs
• 🔒 Secure storage - Encrypted credentials with automatic token caching

Install:

gh extension install AmadeusITGroup/gh-app-auth

Here's the repo:
📦 https://github.com/AmadeusITGroup/gh-app-auth

It is written in GO, released under Apache and all kinds of contributions are welcome.

It's still early days - there may be bugs and rough edges I haven't discovered yet. Would love your feedback, issues, or PRs! 🙏

[qoomon]

you still need to manage app credentials. if you want to get rid of credential management have a look at my approach https://github.com/qoomon/actions--access-token a server/lambda creates short lived app tokens, authentication is realized by the github action oidc tokens

[jlilleby]

This would 100000+ % solve a large headache in our orginization to, if Github where able to make it so that we do not need a Github App for using Terraform modules in internal repos. We do not want to use 50+ PATs to maintain.

[Alexandre-Rib]

Hi,

I'm able to bypass this problem by using git credential, in a personnal action ( developped for my company, I can't share it).
Tested on Powershell , the next lines permit me to download with {{secret.token}} other repos than the one tested by the workflow.

Snippet :

$GIT_TOKEN =$secrets:GITHUB_TOKEN
git -c credential.helper="!f() { printf 'username=git\npassword=%s\n' \"$GIT_TOKEN\"; }; f" clone "$URL" "$Dest"

The bash syntax, according to chatGpt ( not tested) should be :

GIT_TOKEN="${GITHUB_TOKEN}"
git -c credential.helper="!f() { printf 'username=git\npassword=%s\n' \"$GIT_TOKEN\"; }; f" clone "$URL" "$DEST"

I hope this will help you, and respond to your need.
I really think so ! Try it, even the portage wrote by Chatgpt is not accurate. I assure you , git credential is THE solution :-)

[abower93]

It's April, still needing this ability:

As an engineer, I want to connect ALL repos in my Organization, to a private repository in my organization, without configuring a secret and applying it to every repo, and without referencing that secret in my calling workflows.

[qoomon]

@abower93 My action should should work as a workaround. You don't need to deal with any long living credentials.
https://github.com/qoomon/actions--access-token

[hfhbd]

@qoomon What's the difference between your action and the official action: https://github.com/actions/create-github-app-token?

[qoomon]

You don't have to store app credentials for each repository. And each repository can manage fine granular access policies.