Audit GitHub Rulesets with gh ruleset list

gh ruleset list turns a maze of repository and organisation settings into one readable table you can audit in minutes. It reports every ruleset that applies to a repository or organisation and makes the scope and inherited policy explicit, rather than leaving you to click through separate settings screens. The examples use GitHub CLI 2.87.3, installed on the reference machine. Budget about ten minutes for a single repository, longer if you are comparing organisation and repository policy.

• You need: the gh package, a GitHub account authenticated with the relevant access, and a repository or organisation name.
• It will not touch anything: this command only reads rulesets or opens the corresponding web page. It does not create, edit, enable or delete policy, so it needs no elevated Linux privileges and no sudo.

1. Confirm the installed command

Check the binary and version before comparing results with another machine:

$ command -v gh
/usr/bin/gh
$ gh --version
gh version 2.87.3 (2026-02-23)

The exact path can differ on your machine. The version matters because GitHub CLI subcommands and their output change between releases. Ask this installation for the command contract as well:

$ gh ruleset list --help
List GitHub rulesets for a repository or organization.

USAGE
  gh ruleset list [flags]

The installed help uses GitHub's spelling organization. This guide sticks with British organisation in its own prose.

2. List the current repository

From a checked-out repository, run:

$ gh ruleset list

With no options, gh asks GitHub for rulesets associated with the current repository. The normal limit is 30 rulesets, and the columns returned depend entirely on what GitHub sends back. Do not treat an empty list as proof that the organisation has no policy; it may just mean this repository does not inherit one.

Checkpoint: confirm which repository GitHub CLI thinks is current before interpreting the list.

$ gh repo view --json nameWithOwner --jq .nameWithOwner
OWNER/REPOSITORY

Replace the placeholder with the value printed on your machine. If the directory is not a GitHub repository, select one explicitly in the next step rather than guessing what the command inspected.

3. Select a repository explicitly

Use --repo or -R with the documented [HOST/]OWNER/REPO form:

$ gh ruleset list --repo OWNER/REPOSITORY
$ gh ruleset list --repo github.example/OWNER/REPOSITORY

The first form selects a repository on GitHub.com. The second includes a host for a GitHub Enterprise deployment. Use the exact owner, repository and host values for your organisation: running the command from a convenient directory and assuming it checked the repository you meant is a common way to audit the wrong thing.

To request more than the default 30 entries, set --limit:

$ gh ruleset list --repo OWNER/REPOSITORY --limit 100

The option is a maximum, not a promise that 100 rulesets exist. Keep the limit large enough for the audit, then record the value in your report so a later reader knows how the inventory was bounded.

4. Decide whether inherited rulesets belong in the audit

Rulesets configured at higher levels can apply to a repository. The --parents flag controls whether those are included, and it defaults to true:

$ gh ruleset list --repo OWNER/REPOSITORY --parents

Use this form when you need the effective policy visible from the repository, including applicable higher-level rulesets, and do not silently compare the result with a repository-only inventory. The installed command exposes the inclusion switch but no documented inverse switch, so do not invent --no-parents here. Record that the default includes higher-level rulesets, and use the GitHub web interface or another documented API workflow for a narrower policy investigation.

5. List organisation-wide rulesets

Use --org when the target is the organisation itself:

$ gh ruleset list --org ORGANISATION

This is not interchangeable with --repo: it asks for organisation-wide rulesets and requires an access token with the admin:org scope. If that scope is missing, refresh authentication deliberately:

$ gh auth refresh -s admin:org
$ gh ruleset list --org ORGANISATION

Warning: the refresh can change the permissions granted to your local GitHub CLI credential. Review the authentication prompt and your organisation's policy before accepting it, and never paste a token into a shell command or store it in a script. If you only need repository rulesets, use --repo and skip the broader organisation scope entirely.

6. Diagnose an unexpected result

Separate target selection from authorisation first. Check the authenticated account and repository identity without changing any ruleset:

$ gh auth status
$ gh repo view --repo OWNER/REPOSITORY --json nameWithOwner --jq .nameWithOwner

• Wrong repository identity: fix the --repo value or change directory.
• Authentication or permission error: check the account, host and required scope. Re-authenticating does not substitute for repository access granted by the organisation.
• Empty result: this can be entirely valid. The target may genuinely have no rulesets, or inherited rulesets may not be included the way you expected. Repeat the audit with and without --parents, record both commands, and compare the target names. Do not infer that branch protection or other controls are absent just because this one list is empty; rulesets are only one GitHub policy mechanism.

7. Open the list in a browser when needed

The --web flag opens the ruleset list in a browser:

$ gh ruleset list --repo OWNER/REPOSITORY --web

This still selects the target using the CLI options, but the browser is a separate place to inspect details. Treat it as a review aid, not as evidence the terminal inventory used the same account, unless you verify the signed-in identity yourself.

Done means

• Recorded the version and target. You noted the installed GitHub CLI version and the exact repository or organisation target.
• Chose scope deliberately. You decided between current-target rulesets and rulesets inherited from higher levels.
• Raised the limit where needed. You increased --limit when the default maximum of 30 was too small.
• Requested admin:org sparingly. You only asked for it when an organisation-wide listing required it.
• Treated an empty list as a lead, not proof. An empty result is a result to investigate, not evidence that every GitHub policy control is absent.
• Changed nothing. No ruleset, repository, service or Linux system setting was touched.