Assign yourself as a reviewer of your own pull request

[douglaslassance]

It may sound weird, but there are cases where I wanted to review myself. Is there any reason why the creator of a given pull request cannot be assigned as a reviewer?

[Katsute]

If it's your own pull you probably don't need to assign a particular reviewer, considering you can just review it yourself without assignment.

[Katsute]

I think approvals from any account will trigger workflows from the projects beta. I personally have done self approvals using a bot as the middle man.

KatsuteDev/JCore#6 (comment)

Unfortunately this workaround requires a separate bot account to approve it.

[douglaslassance]

That's an acceptable workaround, thanks for sharing. Personally, I don't think I miss the functionality so much that I would go out of my way to set this up. My post was mainly to flag that self-assignment should probably be possible to cover for cases like the ones I described.

[klaus19]

Yeah, self approvval is very much needed as my changes need to be reflected in main branch and I can't just wait for someone to approve the merge , its time consuming.

[lrperlmu]

How about the kind of code review where I invite a colleague to my desk and we review it together, but I'm the one who's logged in at my computer so the collaborative code review looks like it's done by me.

[bressler95tops]

it doesn't allow you to click approve when you initiated it

[aidan-mundy]

There are definitely other reasons that this should be supported. My immediate example is: If you create an MR using a branch developed by someone else, but still want to follow a standardized review process with proper assignments.

[kailukowiak]

Exactly, if I create a PR from dev -> prod but dev has changes from multiple people, I'd like to review them all together.

[stuart909]

I am lead in my repo and created a pull request for a commit from another junior dev. He was not able to do it so I wanted to do it for him so I could get the ball rolling. Now I cannot review the pull request because I technically initiated it. Seems all GitHub has to do is take out the condition that the requester cannot be in the reviewers group. Just my two cents.

[johnny-shepherd]

same

[sdg002]

Azure Devops repository has this feature and has worked very well in my organization. I would like Github to have this feature too.

[ariukkonen]

Same in 2025. Some of us have our own projects and we want to follow the correct workflow in those as well instead of always bypassing the rules or using the commandline.

[bressler95tops]

2026 still a thing

[Arun-warkar]

still same..

[spenserblack]

Another use case for reviewing your own PR: I created a PR for a repo where I'm a collaborator. I then worked with the owner to implement some changes, but in the process I noticed a likely mistaken change that should be resolved before a merge. Specifically, a package-lock.json was added when we already had a yarn.lock. I wanted to mark the PR as "changes requested" so we could discuss which package manager was preferred before a merge, but couldn't because I was the author.
I think it makes sense to review your own PR once it becomes collaborative and has multiple committers, especially for changes that occurred after PR was created.

[douglaslassance]

Now that there is a YOLO badge for people who let un-reviewed PRs go through, I'm being publically shamed for creating reviews for myself that I cannot approve. 😄

[rioki]

Yea... What are you going to do if you are the sole developer on a repro? Not use the PR workflow?

[RalphHightower]

Well, that's what I do.

[mc0re]

If it's a public repo, you need PRs regardless.

[llegaz]

maybe gitlab is better for solo devs..

[pricehatfield]

The SLSA framework allows for trusted contributors to be 1 of 2 minimum reviewers on merges. It still protects against un-validated submissions, but does cut the red tape somewhat for senior team members and alleviate staffing requirements or people doing things not really part of their role. I'd love to see support in Github to assign this by team membership.

[SiJonesDLG]

It remains extremely short-sighted that this is not possible.
I have set up branch protection etc to prepare for incoming junior collaborators on a project where I am currently working solo.
So now I can't merge into the master branch myself? What a dumb limitation. It is just a poor design.

[jimgerth]

For work we are using GitLab, so I only use GitHub for personal side projects.
But for years, each time I start a new project on GitHub I come back to this same issue...
Its really annoying to not be able to go through the proper review process on your own (especially for new developers just getting used to the workflow).
Anyways, just wanted to let out some of my frustration with this.

[Hobart2967]

Alternative suggestion:

Create the PR as draft, then turn it into a real request. Possibly, you could fetch that type of event to check for a "final" PR to be merged and consider it as reviewed.

[rioki]

I actually ended up doing the following:

https://github.com/rioki/ice/blob/master/.github/workflows/auto-approve.yml

Not nice, but it works. I type LGTM as a comment and the actions bot approves the pull request. Same thing, just listening on a comment.

[vivasvan-patel-ev]

link is dead!

[RalphHightower]

I want to do the same myself. I am the owner and sole contributor. But I want to learn more about the GitHub process.

[RalphHightower]

After many attempts, it was by SDL (Sheer Dumb Luck) that I was able to approve and merge a pull request that I created for my solo owned repository.

[RalphHightower]

I have found the solution works for me; I am the only one working in the repository, so it may not be appropriate for other situations. On the settings page, select "Branches". Select "Edit" in the Branch Protection Rule.
Make sure that these two checkboxes are unchecked:

1. Require approvals
   When enabled, pull requests targeting a matching branch require a number of approvals and no changes requested before they can be merged.
2. Require approval from someone other than the last pusher
   Require review approval from someone other than the last pusher to the pull request branch.

[rioki]

That works, but merging is not approving. As project admin you can hit the red button at any time and override the approval steps. But this locks you out of auto merging when a build passes or some other automated checks. The whish is to be able to review your own code and actually punch the approve button and maybe even make workflow dependent on this.

Right now the possible solutions are all hacks, like my auto-approve.yml workflow how you can have the build bot approve on your behalf.

[RalphHightower]

Yea, that's not gonna work, other than your auto-approve workflow. I found that GitHub prohibits one from approving their own pull request.

[cx0y]

It may sound weird, but there are cases where I wanted to review myself. Is there any reason why the creator of a given pull request cannot be assigned as a reviewer?

Don't know ! but count me in, I wanna review myself :)

[llegaz]

microsoft teams' members are not able to introspection it seems

[reespozzi]

Seconded, another good use case is automated pull request workflows, the author (a bot in this case) should be able to approve it's own PR if it's something trivial and checks all pass.
It would be nice to keep the required reviews in place for PR's authored by humans, but allow complete auto-merge functionality for bots

[RalphHightower]

I don't think that auto-approving pull requests is a good idea. I think a human should be involved in approving pull requests. What happens if automation breaks the build process? Ralph

…

On Mon, Dec 12, 2022, 6:53 AM Rees Pozzi ***@***.***> wrote: Seconded, another good use case is automated pull request workflows, the author (a bot in this case) should be able to approve it's own PR if it's something trivial and checks all pass. It would be nice to keep the required reviews in place for PR's authored by humans, but allow complete auto-merge functionality for bots — Reply to this email directly, view it on GitHub <#6292 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHZ2PYWBE5ABAXX3IUYA3V3WM4G2JANCNFSM5F5L4RWQ> . You are receiving this because you commented.Message ID: ***@***.***>

[ucswift]

Throwing my 2c into this for a use case. I'm currently the only dev at a small biz and trying to setup the dev pipeline to be compliant with a number of industry certifications. Most of those, around the area of change management, require some approval process for changes into production (which I use a CI pipeline based off the master branch to do). I would be nice if self approval worked out of the box as that would allow a process to be in place that scales right out of the box and is consistent.

[jimgerth]

One more thing besides all of the other comments:
Maybe I'm missing something, but it seems like you need to be a reviewer of a pull request to be able to change its draft status.
This means, that I cannot create a draft pull request as a solo developer, which is simply ridiculous in my opinion.

[jimgerth]

Update: I still cannot assign myself as a reviewer of my own PR, but as of today I can convert my own PRs to drafts, which is all I really asked for anyway 🥳

[vivimage]

Another use case -
You created a pull request through open ai codex agent. And now you want to review and approve it but you cant

[MarkS-AL]

Can't believe this issue remains unresolved.
This action will approve as [github-actions], supply the PR number as the job run arg:

on:
  workflow_dispatch:
    inputs:
      pr_number:
        description: 'PR number to approve'
        required: true
        type: string

jobs:
  approve:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
        
      - name: Approve PR
        run: |
          gh pr review ${{ inputs.pr_number }} --approve
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

You need to manually merge after approval.

[abjugard]

Super annoying, what the hell Github...

[PaulAtST]

This would be a very useful option to add. I have ran into mutiple situations where this would have been helpful.

The most recent one was a PR where everyone on the team contributed something to it. This forced the creator of the PR to leave there feedback outside of GitHub.

[mrtns]

In an era where various AI is involved in some, or all, parts of code generation (and unattribued with a distinct committer or github user), being able to "self review" a PR is becoming necessary. Not to work around any PR rules, but simply as another step in the workflow.

[towry]

@github It's time to allow assign self as reviewer and allow review own PR

[gillhawkes1]

Everyone, I am going to save you some time. I have been monitoring this thread for over 3 years, Github has no intentions of bringing this feature to production. It is seemingly an obvious use case that every single person in here would want, but for some reason it is either not a priority for the dev team to add or it has been deemed as a feature that doesn't need to be added ever.

[SyedShaheerHussain]

it’s mostly a design + process choice, not a technical limitation. Platforms like GitHub intentionally discourage or block self-review to preserve the meaning of “review.”

[spenserblack]

I understand the reasoning as a sort of separation of duties. You don't want the sole reviewer to be the author, because they'll probably have a favorable bias towards their own code, and overall it just doesn't really have much meaning when an author reviews their own code. Hopefully they already think their code is good-to-merge if they submitted a PR and it's not a draft. But Git is a collaborative tool, and this can include multiple authors working on one branch, which can become multiple authors working on one PR.

As I mentioned above, in one situation I authored a PR and then someone else committed to the same branch and updated the PR. That change added an issue, so I wanted mark a PR as "changes requested" but couldn't.

In another situation, I figured that I would be helpful and make a PR from a beginner's fork to a repo I maintain, because they were new and nervous to make the PR on their own. I quickly learned that, being the creator of the PR, I was blocked from doing a proper review, even though I was not the author of the commits nor the owner of the fork. I had to close the PR and ask that beginner to just make the PR themselves, and wasted their and my time on a PR I couldn't properly review.

Since GitHub introduced branch protection rulesets, those would be a much better way to enforce the "you can't review your own PR" rule, rather than simply block every PR from being reviewed by its own author all the time. I think this would go nicely as an option under "require a pull request before merging" in some form. In other words, I think that authors should be free to submit reviews for their own PRs, and it should be the admin's choice whether or not those reviews matter.

[PaulAtST]

If GitHub wanted to enforce a review, just make it that the creator of the PR can't be the only reviewer. The problem is the current flow is getting teams into situations were if we don't do extra work code gets merged with no review.

[bressler95tops]

I was able to get around it by adding admins as a condition of the bypass list. This works in my case since the other people in the repo are going to be maintainers. This may not work in all situations though, i.e when there is multiple admins. Maybe utilizing custom roles would work. Either way it seems kind of rigid as you can't select a particular user. I understand that GitHub is meant to be a collaboration platform but as the project admin, I would rather be able to merge my own PRs.

[Girmii]

+1, make it happen GitHub team...

[lewandowski96]

Will this happen in 2026?

[mintleaf84]

i need

[svioletg]

Would love to see this implemented. It would be nice to still follow a standard procedure even if you're the owner of a repository or something.

[douten]

Here comes a sassy developer. In the year of our good lord 2026 I still can't believe a multi Trillion dollar company can't prioritize this with how much the community is asking.
Oh wait! actually I can, I know what they're prioritizing instead..

[nicodes]

This would be great for my reviewer subagents