Fine‑grained PATs cannot be used to verify whether a user is an organization owner (admin) — API returns empty admin list unless using classic PAT with read:org

[SkybuckFlying]

Problem Summary

I am building a tool that needs to determine whether the authenticated user (via PAT) is an owner/admin of a GitHub organization. This is required before allowing automated repository creation and other org‑level operations.

The problem is that fine‑grained personal access tokens cannot be used for this, because the GitHub API does not return organization admin/member information unless a classic PAT with read:org is used.

This makes it impossible to reliably detect organization ownership using fine‑grained tokens.

---

Technical Details

1. API calls used

My tool uses the documented endpoints:

• GET /user
  → to identify the authenticated user
• GET /users/{org}
  → to detect whether the target is a user or an organization
• GET /orgs/{org}/members?role=admin
  → to check if the authenticated user is an organization owner
• GET /orgs/{org}/memberships/{username}
  → fallback membership check

2. Behavior with classic PAT (works correctly)

When using a classic PAT with scopes:

• repo
• read:org

the API behaves as expected:

• /members?role=admin returns the full list of organization admins
• the authenticated user appears in that list
• ownership can be reliably detected
• repository creation works

3. Behavior with fine‑grained PAT (broken / incomplete)

When using a fine‑grained PAT, even with:

• full repository access
• access to all repositories in the organization
• the token visible under the organization’s “Active fine‑grained tokens”
• the token approved by the organization

the following happens:

• /orgs/{org}/members?role=admin returns HTTP 200 but an empty array
• /orgs/{org}/memberships/{username} returns 403 Forbidden
• the tool cannot determine whether the user is an owner
• repository creation is denied because ownership cannot be verified

4. Root cause

Fine‑grained PATs cannot request or receive organization‑level permissions such as:

• reading organization members
• reading organization admins
• reading private membership
• verifying ownership

Even if the token has full repository access, the organization permissions section always shows:

“This token does not have any organization permissions.”

This makes it impossible to use fine‑grained tokens for any workflow that requires org‑level identity or ownership checks.

---

Why this is a problem

GitHub is encouraging users to migrate from classic PATs to fine‑grained PATs, but:

• fine‑grained PATs cannot perform basic organization‑level operations
• they cannot verify whether the authenticated user is an org owner
• they cannot read org members or admins
• they cannot replace classic PATs for tools that need org‑level access

This leaves developers in a situation where:

• classic PATs work
• fine‑grained PATs cannot be used
• there is no documented alternative

---

What I am asking GitHub

1. Is there a supported way for a fine‑grained PAT to read organization admins or membership?
2. If not, is this a known limitation or a bug?
3. Will fine‑grained PATs eventually support read:org‑equivalent permissions?
4. Is there a recommended migration path for tools that need to verify organization ownership?

---

Conclusion

Right now, fine‑grained PATs cannot replace classic PATs for any tool that needs to:

• check if a user is an organization owner
• read organization members
• perform org‑level operations

This seems like a significant gap in the fine‑grained token model, and I would appreciate clarification or guidance on how to handle this use case going forward.

[ViteDelphi]

A solution would be to leave the check out of it, the check which verifies if it's an owner/admin has the correct rights etc, and use a trail and error approach, however applieing this to the creation of many repoes would create a lot of "failure" spam.

Thus this creates a desire to have an API to prevent this trail and error approach to not waste bandwidth and not do a trail and error approach... also to prevent halfly or wrongly constructed repos where some actions succeed and some fail becomes of not enough rights etc...

Intended use case for tool is creating many git submodules for dependencies which will be forked to allow code changes to the dependencies.

All AIs agree, one AI wanted me to mention this, maybe it helps you understand the problem a bit better:

"This creates a security paradox: to perform a simple check if a user is an admin, developers are forced to use a Classic PAT with broad read:org scopes, which grants more access than desired, simply because Fine-grained PATs lack the granular 'Organization Members' read permission."

[ViteDelphi]

I tried this approach and it also did not work:

When using a fine‑grained GitHub Personal Access Token (PAT), every attempt to create a repository inside a GitHub organization fails with HTTP 403 Forbidden. This happens even when the token has all available repository‑related permissions enabled. The reason is that fine‑grained PATs do not support organization‑level repository creation rights. GitHub does not allow fine‑grained tokens to create new repositories in organizations, regardless of the permissions selected.

As a result, the tool correctly attempts to create each repository, but GitHub consistently returns:

HTTP 403 Forbidden
Your token cannot create repositories here.
This is expected with fine-grained PATs without org repo creation rights.

This behavior is expected and cannot be resolved in the tool itself. To successfully create repositories in an organization, a classic PAT with the repo (and optionally read:org) scope is required. Fine‑grained PATs are only suitable for accessing or modifying existing repositories, not for creating new ones.

[Sonra0]

1. Is There a Supported Way to Read Org Membership with Fine-Grained PATs?Not currently. Fine-grained PATs support repository-level and some account-level permissions, but organization membership and admin status are not exposed regardless of what repository permissions the token has. The empty array from /orgs/{org}/members?role=admin is expected (not a bug in your code) — the token simply lacks the scope to see that data.2. Is This a Known Limitation or a Bug?It is a known limitation, not a bug. GitHub has acknowledged that fine-grained PATs have a gap in organization-level permissions. You can follow the discussion here:

GitHub Feedback: Fine-grained PAT org permissions
3. Will Fine-Grained PATs Eventually Support read:org-Equivalent Permissions?GitHub has indicated this is on their roadmap, but there is no committed timeline. Organization-level permissions for fine-grained PATs are actively being developed. Watching the community discussion linked above is the best way to track progress.4. Recommended Migration Path Right NowUntil fine-grained PATs support org permissions, your realistic options are:Option A — Keep using classic PATs with read:org
Not ideal for security, but it works reliably today. Scope it as narrowly as possible (read:org + repo only).Option B — Use a GitHub App instead
This is GitHub's recommended replacement for org-level automation:

GitHub Apps can request members: read organization permission
They support fine-grained, per-installation access control
They are better suited for tools that act on behalf of organizations
See: GitHub Apps documentation
Option C — Require the user to explicitly confirm org ownership
If switching to a GitHub App isn't feasible, you can skip the API ownership check entirely and instead:

Ask the user to confirm they are an org owner during setup
Attempt the org-level operation and handle the 403 gracefully as a permissions error