You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
HttpError: You do not have permission to create labels on this repository #870
Action should have permission to create labels, since the built-in GITHUB_TOKEN secret is being used and pull-requests: write permissions are configured.
Actual behavior:
Workflow fails with permissions error:
Reacted by Koos van Wijk, hiro, Logan Yott, Robert Gernert, ReStartAllKill, Preston Thorpe, Kyle Barstow, Junya Okabe, Pieter C and Sami
Hi @matejchalk ,
Following a recent test using a forked repository and pull request, I can confirm that the labeler is functioning correctly. While there were transient permission issues related to GITHUB_TOKEN observed on 2025-05-14, these did not persist in subsequent workflow runs.
For users who may still be encountering similar issues, I’d like to highlight two recommended approaches that can help ensure smooth labeler functionality:
1. Define Explicit Workflow Permissions
GitHub processes pull requests as issues internally, which means applying labels requires access to the Issues API. To enable this, your workflow must explicitly declare the necessary permissions. Be sure to include the following block in your workflow file:
This ensures the default GITHUB_TOKEN has sufficient access to apply and sync labels correctly.
2. Use a Fine-Grained Personal Access Token (Optional)
For enhanced control or scenarios where the default token scope is insufficient, you can use a fine-grained personal access token (PAT) with appropriate scopes (e.g., Issues or Pull requests with Read/Write access).
Store the PAT as a repository secret (e.g., PERSONAL_ACCESS_TOKEN), and reference it in your workflow like so:
I hope this helps clarify the setup for others. If you continue to face issues or need further assistance, feel free to reach out.
Thanks again to everyone for your collaboration and contributions in making this project better!
@chiranjib-swain Thanks for investigating this 🙂 It does indeed seem like it was a temporary problem, the labeler action has since been working just fine in our subsequent PRs, without any configuration changes on our end.
1. Define Explicit Workflow Permissions GitHub processes pull requests as issues internally, which means applying labels requires access to the Issues API. To enable this, your workflow must explicitly declare the necessary permissions. Be sure to include the following block in your workflow file:
Hi @sciencewhiz
Thank you for bringing this up! We've noticed that the README.md for actions/labeler doesn't consistently mention the need for issues: write permission across all relevant sections. Based on our observations, the behavior appears to vary—some users are able to use the labeler without explicitly setting this permission, while others encounter issues unless it's specified.
We're actively monitoring these cases to better understand the underlying cause. If it becomes clear that this is affecting a broader group of users, we’ll consider suggesting a documentation update or feature enhancement to clarify the required permissions.
In the meantime, if you’re experiencing permission-related issues, explicitly adding issues: write to your workflow permissions is a recommended and effective workaround. We appreciate your feedback and welcome any additional insights you may have!
Also ran into this issue and also for us the issues: write permission fixed it. I do want to share here that we ran into it after adding labels that don't exist at all in the repo yet. For existing labels the pull-requests: write permission appears to be sufficient because it only adds existing labels to a PR, which probably only edits the PR itself and not the labels. However, it makes sense that persisting non-existing labels requires an additional permission to create a new label, and apparently issues: write does that.
Creating the labels for the labeler workflow manually probably also fixes it, but that's not very convenient of course.
I guess changing the Readme as done here helps other people running into it, but wouldn't it be nice to catch this error and suggest to add the issues: write permission or to create the missing labels manually?
Activity
RobertGernert-TomTom commentedon May 15, 2025
I could fix this in my workflows by adding the permission
issues: write[CI] Fix labeler action (#7928)
v-aparnajyothi-y commentedon May 21, 2025
Heloo @matejchalk, Thank you for creating this issue and we will look into it :)
v-chiranjib-swain commentedon Jun 10, 2025
Hi @matejchalk ,
Following a recent test using a forked repository and pull request, I can confirm that the labeler is functioning correctly. While there were transient permission issues related to
GITHUB_TOKENobserved on 2025-05-14, these did not persist in subsequent workflow runs.For users who may still be encountering similar issues, I’d like to highlight two recommended approaches that can help ensure smooth labeler functionality:
1. Define Explicit Workflow Permissions
GitHub processes pull requests as issues internally, which means applying labels requires access to the Issues API. To enable this, your workflow must explicitly declare the necessary permissions. Be sure to include the following block in your workflow file:
This ensures the default
GITHUB_TOKENhas sufficient access to apply and sync labels correctly.2. Use a Fine-Grained Personal Access Token (Optional)
For enhanced control or scenarios where the default token scope is insufficient, you can use a fine-grained personal access token (PAT) with appropriate scopes (e.g., Issues or Pull requests with Read/Write access).
Store the PAT as a repository secret (e.g., PERSONAL_ACCESS_TOKEN), and reference it in your workflow like so:
I hope this helps clarify the setup for others. If you continue to face issues or need further assistance, feel free to reach out.
Thanks again to everyone for your collaboration and contributions in making this project better!
matejchalk commentedon Jun 10, 2025
@chiranjib-swain Thanks for investigating this 🙂 It does indeed seem like it was a temporary problem, the labeler action has since been working just fine in our subsequent PRs, without any configuration changes on our end.
sciencewhiz commentedon Jun 14, 2025
README.md does not show the
issues:writepermission in either location where permissions are discussedv-chiranjib-swain commentedon Jun 18, 2025
Hi @sciencewhiz
Thank you for bringing this up! We've noticed that the
README.mdforactions/labelerdoesn't consistently mention the need forissues: writepermission across all relevant sections. Based on our observations, the behavior appears to vary—some users are able to use the labeler without explicitly setting this permission, while others encounter issues unless it's specified.We're actively monitoring these cases to better understand the underlying cause. If it becomes clear that this is affecting a broader group of users, we’ll consider suggesting a documentation update or feature enhancement to clarify the required permissions.
In the meantime, if you’re experiencing permission-related issues, explicitly adding
issues: writeto your workflow permissions is a recommended and effective workaround. We appreciate your feedback and welcome any additional insights you may have!Fix labeler
ci: add missing permissions to labeler action
TheColorman commentedon Jul 4, 2025
+1 for needing the
issues: writepermission. Copied the examples from the README and got the error, was resolved when I added the permission.robinborst95 commentedon Jul 15, 2025
Also ran into this issue and also for us the
issues: writepermission fixed it. I do want to share here that we ran into it after adding labels that don't exist at all in the repo yet. For existing labels thepull-requests: writepermission appears to be sufficient because it only adds existing labels to a PR, which probably only edits the PR itself and not the labels. However, it makes sense that persisting non-existing labels requires an additional permission to create a new label, and apparentlyissues: writedoes that.Creating the labels for the labeler workflow manually probably also fixes it, but that's not very convenient of course.
I guess changing the Readme as done here helps other people running into it, but wouldn't it be nice to catch this error and suggest to add the
issues: writepermission or to create the missing labels manually?FIX: autolabel workflow/ set correct permission
DOC: Add sphinx-gallery (#27)