In order to solve #639, we need to either (1) switch repository creation to the REST API or (2) ask users to authorize an additional org:read OAuth scope.

I initially gravitated to (1), but by now I'm thinking that (2) would be a better approach in the long term because:

• adding extra fields such as assignees or reviewers to issues/PRs will require the org:read scope to present the prompt UI Add relevant metadata to issue view and pr view #663
• a command with direct access to API will need additional OAuth scopes depending on which API features will users access through it Direct access to GitHub API via gh #332

For new CLI users, adding another scope is just a matter of changing one line and shipping that

However, existing CLI users already have an OAuth token cached in ~/.config/gh/config.yml, so we would need to ask them to re-authenticate. After the first API request with the old token, we could detect from the API response that the required scope is missing, and then either:

1. Warn the user about insufficient scopes, abort the operation, and ask them to rm ~/.config/gh/config.yml and try again. This approach is easiest to implement, but I feel that it might be detrimental to the user experience. Also, after the config features ship Enable configuration in gh (gh config) #622 that file will contain more configuration than just authentication info, so I would like us to avoid training our users to ever manually delete that file.

2. Abort the operation and ask users to re-authenticate using a command like gh auth or gh login. We don't have such a command yet, but it was asked for Additional or alternative authentication method #297 and I think it would be useful both as an official way to reauthenticate and to check authentication status for different hosts (github.com vs. GHE).

3. Don't abort the operation, but ask the user to re-authenticate interactively by printing something like “Re-authentication needed. Press Enter to open github.com in your web browser” and proceed with the original operation using the new token. This is the least intrustive option, but it will involve some code juggling to be able to retry an operation. (We should also avoid ever retrying a write operation.) Using this approach we could also resolve other token problems such as the case when the token was revoked No CTA after mistaken deletion of oauth access #627

4. …some other approach that I haven't considered? I'd like to hear your thoughts.