I have searched through the issues and didn't find my problem.
Bug description
Currently, the in-develop issue labeler is not working properly (see this. The issue is due to the GITHUB_TOKEN being limited in scope when used in forked repos.

Since all PRs are from forked repos, it renders the workflow unable to edit the Issues in our repo.
Possible fixes or solutions
I was going to try this solution. It involves giving the workflow access to these permissions to add the label. However, this is not recommended since our workflow involves checking out the repo => might open ourselves up to pwn requests. It also seems like we can't override the access for forked repo as seen in this link
New possible solution: follow the pattern that's being used by our peek-bot:
- The
pull_request PR saves the PR number/issue number into a file
- Upload it as an artifact
- Create a
workflow-run workflow that runs after the first PR
- Get the artifact and label our issue in here where we get full GITHUB_TOKEN access.
Since workflow_run workflows has to be in the default branch to work, this would prevent security issues.
Additional information
For now, we can label or the issues manually after merging. It's a bit annoying but not too difficult.
I have searched through the issues and didn't find my problem.
Bug description
Currently, the in-develop issue labeler is not working properly (see this. The issue is due to the

GITHUB_TOKENbeing limited in scope when used in forked repos.Since all PRs are from forked repos, it renders the workflow unable to edit the Issues in our repo.
Possible fixes or solutions
I was going to try this solution. It involves giving the workflow access to these permissions to add the label. However, this is not recommended since our workflow involves checking out the repo => might open ourselves up to pwn requests. It also seems like we can't override the access for forked repo as seen in this link
New possible solution: follow the pattern that's being used by our
peek-bot:pull_requestPR saves the PR number/issue number into a fileworkflow-runworkflow that runs after the first PRSince
workflow_runworkflows has to be in the default branch to work, this would prevent security issues.Additional information
For now, we can label or the issues manually after merging. It's a bit annoying but not too difficult.