GitHub actions are severely limited on PRs

Currently, the GITHUB_TOKEN only has read permission to pull requests when access by forked repos. 

This is refer to official document: 

For all your requirements on PR from forked repo, I would encourage you sharing those in the Feedback form for GitHub Actions. Thank you for your understanding. 

1 Like

Seriously? A canned answer? I obviously did read the documentation. You’ve missed the entire point. That’s shameful.


Hi @ecco , 

I really understand your scenario and you are looking forward to a write permission of GITHUB_TOKEN to act on pull request from fork.  

But I am so sorry that this is not supported now. 

Feedback form for GitHub Actions is a more suitable site to share your idea : adding some additional scopes to the GITHUB_TOKEN to enable commenting , labeling on PRs. The feedback will be checked by GitHub Engineering team directly. 

>>Allow Actions to return more than a “fail/pass” result. Maybe at least a string that would be commented on the PR would be a good start?

There is a set-output command which could set output variable for a step with string value.  You could use the output variable in the next steps of current job. 

But unfortunately,  it still could not be commented on the PR.  


May this be a working workaround for this problem?

1 Like

OK, here’s an experiment I made where I was sure it would work and be a workaround for the problem you describe. But I was wrong…

First, create an access token in your settings with sufficient “repo” permissions on the repo you have set up your actions.

Store that token as secret, e.g. RW_TOKEN, in the repo you have set up your actions.

Create an action YML:

name: create issue on PR/push

on: [pull_request,push]

    runs-on: ubuntu-latest
    - name: Run a multi-line script
        RW_TOKEN: ${{ secrets.RW_TOKEN }}
      shell: bash
      run: |
        curl --request POST \
        --url \
        --header 'authorization: Bearer'" $RW_TOKEN" \
        --header 'content-type: application/json' \
        --data '{
          "title": "Automated issue for commit: ${{ github.sha }}",
          "body": "This issue was automatically created by the GitHub Action workflow **${{ github.workflow }}**. \n\n The commit hash was: _${{ github.sha }}_."

This code, using the RW_TOKEN copied and run in a terminal on my machine executes just fine. Triggered by a push, the action runs just fine and create the issue. Triggered by a PR from a forked repo , it fails with:

  "message": "Bad credentials",
  "documentation_url": ""

THIS IS JUST CRAZY, isn’t it??? 

1 Like

As frustrating as this is, it does make sense that the same issue would apply to secrets as it does for the built in GitHub Token. Otherwise that would be a major security flaw. However this is a MAJOR oversight on GitHub’s part. There needs to be some solution to handle this extremely common workflow.


This actually makes a majority of use cases that I have for GitHub Actions useless and would force me to look to external integrations. Can someone from GitHub comment on whether this is being investigated? Or is this “just the way things are going to be”?

1 Like

I have seen mention elsewhere that this is (was) being looked into. I’ll see if I can dig the details up again.

1 Like

Agreed - the #1 use for github actions in my mind is around making the contribution process simpler, automated, and bullet proof. But since we can’t support any features that matter with contributed updates then it is useless.

All we need is the ability to automatically use the workflow from the TARGET branch instead of the PR itself – but giving it access to the branch being merged. It really doesn’t seem that difficult? Although I am sure I am missing something?


I’ve updated the add-pr-comment action I maintain to make this as easy as possible until GitHub comes up with a better solution. I created a simple proxy app which can be deployed via a Cloud Run Button, and allows specifying the proxy URL as an override in the action. I imagine most use will fall in the Cloud Run free tier.


I accomplished this without a github app actually. @mshick this actually maeks PR comments on forked PR as well as run full checks / linting on them so it may be a good example of how you could accomplish your action as yours would be 10,000x simpler :slight_smile:

1 Like

So the artifacts generated from the fork are available to the scheduled run on the upstream / original repo? Great discovery, thanks!

I’ll look at incorporating something similar, could definitely be useful for those who don’t mind the lag time and would rather not host a proxy.


Only when using the REST API - the @actions/artifact specifically restricts it to the current workflow run only and doesn’t make it available to the workflow as a whole.

I was planning at some point to bundle it up into a easy workflow to use, if possible.

1 Like

GitHub has introduced a new event type: pull_request_target, which allows to run workflows from base branch and pass a token with write permission.

In order to solve this, we’ve added a new pull_request_target event, which behaves in an almost identical way to the pull_request event with the same set of filters and payload. However, instead of running against the workflow and code from the merge commit, the event runs against the workflow and code from the base of the pull request. This means the workflow is running from a trusted source and is given access to a read/write token as well as secrets enabling the maintainer to safely comment on or label a pull request. This event can be used in combination with the private repository settings as well.


I believe I tried that, but since it runs against the workflow and code from the base of the pull request, it makes it impossible for my action to retrieve the list of changes files from the forked repo to run tests on them. The alternative (in my case) would be to re-rest the entire repo, not only changed files.

I’d loved to be proven wrong here, so if anyone knows, feel free to comment.

1 Like

I think pull_request_target, can do what you need. Just make sure your checkout gets what you need, ex:

     uses: actions/checkout@v2
        ref: ${{github.event.pull_request.head.ref}}
        repository: ${{github.event.pull_request.head.repo.full_name}}

For changed/added files you can also checkout: futuratrepadeira/changed-files.

Here’s an example that you could use as a model:


Is this still safe if the action calls any scripts from the repo? If the GITHUB_TOKEN is not stored in an env var I don’t think a malicious PR could steal the token…

1 Like

GITHUB_TOKEN is fairly safe as it is only valid for the duration of the workflow run.

1 Like

I disagree with this; if the token was in an env var (it isn’t, I tested it), then any CI where the workflow yaml calls external scripts in the repo would be vulnerable to someone sending a PR that modifies such a script in order to abuse the token.

Sure, the impact would be limited, but you could still use it to cause some chaos in the repo! And I could totally imagine script kiddies searching GitHub for repos vulnerable to this programmatically “just for the lulz”.

1 Like

I guess that’s why pull_request_target workflows don’t run for PRs that add or modify them.

1 Like