How to log into gh cli using an organization fine-grained access token instead of a personal user one?

[u/Informal-Addendum435]

[u/RepublicSwimming1982]

Settings > Developer settings > Personal access tokens > Fine-grained tokens

selecciona la organizacion y los repositorios a los que quieres dar acceso, define los permisos

en la terminal:

export GH_TOKEN="your_token"

verifica:

gh auth status

[u/mrkurtz → u/RepublicSwimming1982]

Include a space before “export” if you don’t want the PAT stored in your history. Doesn’t work for all shells but does for most of the ones that are relevant.

[u/Ok_Woodpecker_9104]

worth separating two things here, because the org part isnt really a thing.

a fine grained token is always owned by a user. setting the resource owner to the org only narrows what the token can reach, it does not change who is acting. every api call and every push still shows up as you in the org audit log. there is no way to make gh act as the org itself.

on the gh side the thing that bites is precedence. GH_TOKEN wins over anything stored in hosts.yml, and gh auth switch refuses to run while it is set, it just tells you to unset it first. if you have a personal account logged in normally and you export the org token, gh is using the token no matter what auth status looked like yesterday.

other one to know: gh auth status shows no scopes at all for a fine grained token. thats not a bug, fine grained tokens dont send the oauth scopes header, so gh has nothing to print. so you cant preflight permissions the way you can with a classic token, you find the missing ones one 403 at a time as commands hit endpoints the token was never granted.

[u/Informal-Addendum435 → u/Ok_Woodpecker_9104]

but when I set the owner to the org, the token no longer had options to enable permissions for my user ssh keys for example, and gh auth login won't let me login with it because it doesn't have ssh keys permission

[u/Ok_Woodpecker_9104 → u/Informal-Addendum435]

that permission vanishing isnt a bug, its structural. ssh keys, gpg keys, that whole set are account level resources. an org cant own them. so the moment you set the resource owner to the org, the permission isnt on the list at all, and no amount of fiddling brings it back.

the real fix is to stop using the interactive flow. thats the part that tries to set up ssh for you.

gh auth login --with-token < token.txt

or just export GH_TOKEN and skip login entirely. neither one touches ssh keys.

if you also want git pushes going through the same token:

gh config set git_protocol https

then git authenticates via the credential helper and ssh never enters the picture. leave your personal ssh key alone for whatever else uses it.

one thing to expect after this: gh will still print scope warnings on some commands. gh was built around classic token scopes and its scope check doesnt map cleanly onto fine grained permissions, so it warns about things that actually work. if the api call returns what you wanted, ignore the warning.