Feature Request: "Optional" permissions


It would be great if GitHub Apps could have “optional” permissions. If its helpful as a reference, Google’s Chrome Extension Platform offers optional permissions and a workflow for prompting users to grant them.

Here’s the use case: my GitHub App does not get access to code by default. But for certain advanced features, it requires code access. It would be great if users could enable code read access when opting into advanced features vs granting that access when they are first trying out the app.


@abinoda thanks for the feature request. We’ve heard from several integrators that optional permissions would be useful for GitHub Apps and we agree. :+1:

I don’t have any information on the timeline but this is under consideration for our roadmap.


I’d love this for Dependabot, too, and there’s a separate thread of other integrators who’ve requested it here. Would allow us to keep the permissions Dependabot asks for as minimal as possible, and dependent on the setup that users want.

Our specific use case is that we hear from some users that they don’t want Dependabot to have write access to their code, and instead want us to create PRs from a fork. We can’t support that flow at the moment because for every open-source user who wants it we have 4/5 private repo users who would find it weird. Because we can’t ask for different permissions from different users we’re stuck with a one-size-fits-all model that isn’t perfect. If write access to code was an optional permission, or if there was some other way to ask for different permissions from different users, then we could explain that to users and get them to pick the option that worked best for them.


:wave: @greysteil,

thanks for the detailed use-case. I will make sure this feedback is considered when working on that feature. Unfortunately there is nothing on the roadmap about this.



:+1:, can totally understand that. From my VP Product days I can see that this one is a real can of worms!

Let me know if / when you do review how permissioning for apps works :slightly_smiling_face:


Saw the update on Option to write a note to users when requesting additional permissions and was curious if there were updates or plans for this?


@abinoda unfortunately no news on this one :crying_cat_face:


I’d like to see this as well, both for apps I use and apps I’d like to create.


I want to +1 this again :sweat_smile: I’m working on a new app now where I want to offer some features that use code read access only if the user wants to enable it. Making code read access required for all installations would greatly hurt adoption.

My experience with Pull Reminders is that App permissions are a big deal – often reviewed in detail by a prospective customer’s security team. Code access is very sensitive and would be a significant blocker for people who want to use the app but cannot not to due to security concerns (ie. their security team does not approve it). So it would be great to be able to make this permission optional so each customer can decide whether or not they want to enable it, and then use the associated features.


The way to achieve this now would be for me to create two separate GitHub apps – one with the minimal permissions, and another one with full permissions – and then have both apps hooked up to my same app.

@vroldanbet @jamesmartin Any new thoughts on this? Also does my immediate solution seem workable?


To go into a little more detail on the approach I just posted about:

  1. I would create two GitHub Apps with the different permission sets – both GitHub Apps would be pointed at my same app server.
  2. Users would initially install the GitHub App with minimal permissions (for on-premises, it would just default to the app with full permissions). Then, they would be prompted to optionally install the app with greater permissions (I would just update the installation id and a permission flag for the existing installation entry in my database… and also keep a separate ledger of all installations in order to keep track). I would have the user uninstall the other app, mainly so I’m not getting duplicate webhooks for every event–although, I could also just ignore webhooks by looking at the installation id.
  3. In my app, I would distinguish which GitHub App was installed by looking at permissions property in the installation info (in webhook payloads and API responses).
  4. When making API calls, I would generate JWTs using the private key associated with the GitHub App installed.


@abinoda, thanks for the further clarification. The approach you describe seems like the most feasible way to achieve what you need today, albeit with a lot of work on your side.

I’ve added your proposed workaround to our internal tracking issue and we’ll keep that use-case in mind as we’re planning work in this area.