Inspect GitHub Rulesets Safely with gh ruleset view

gh ruleset view shows exactly what one GitHub ruleset does, without you hunting through nested repository and organisation settings pages. You finish with a repeatable way to check whether a rule is inherited, and a clear sense of the line between viewing policy and changing it. The examples match GitHub CLI 2.87.3, installed here in the gh package.

Budget about ten minutes. You need the gh command, access to the target repository or organisation, and an authenticated GitHub CLI session with permission to read its rulesets. This guide only reads rulesets or opens their web page; it does not create, edit, delete or disable policy.

1. Confirm the installed command

Check the binary and its version before relying on the examples below. These are ordinary, read-only commands and need no elevated privileges:

$ command -v gh
/usr/bin/gh
$ gh --version
gh version 2.87.3 (2026-02-23)
https://github.com/cli/cli/releases/tag/v2.87.3
$ gh ruleset view --help

The command's shape is gh ruleset view [ruleset-id] [flags]. The ruleset ID is numeric in the upstream examples; what matters is that it identifies an existing ruleset. Do not guess an ID when you can select one interactively or pull it from a trusted administrative record.

Checkpoint: confirm that the version shown by your machine is the one this guide describes. The local help output is the real contract if your package is newer or older.

2. Check authentication and repository context

Before viewing a ruleset, confirm the account and host gh will use:

$ gh auth status

Read the result carefully if you work with more than one GitHub host or account. A successful login does not guarantee access to every repository or organisation, and the view command can still fail when the selected account cannot read the target ruleset.

If the repository is not your current working directory, select it explicitly with --repo. Use the full [HOST/]OWNER/REPO form for GitHub Enterprise:

$ gh ruleset view 23 --repo OWNER/REPOSITORY

Replace both uppercase placeholders with real values. This reads the ruleset with ID 23 and its applicable parents; it does not change the repository. Skip sudo here: elevated local privileges do not grant GitHub API permissions, and can even point the command at a different configuration or credential store.

3. Select a ruleset interactively

When you do not know the ID, omit it:

$ gh ruleset view

The installed command opens an interactive prompt to choose a ruleset that applies to the current repository. Select the exact entry you mean to inspect, then read the displayed policy. The list can include rulesets inherited from higher levels, because --parents defaults to true.

Interactive selection is fine for a one-off check, but it is a distraction in scripts: it needs a terminal and a human choice. For a repeatable audit, use an explicit ID, repository and parent setting instead.

4. Separate local rules from inherited rules

GitHub rulesets can apply through a repository's organisation or other higher-level configuration. Start with the default view when you need the effective policy, including applicable parents:

$ gh ruleset view RULESET_ID --repo OWNER/REPOSITORY

To inspect only rulesets configured at the selected repository level, disable parent inclusion:

$ gh ruleset view --no-parents --repo OWNER/REPOSITORY

--no-parents is the negated form of the boolean --parents option. It is easy to miss, because the help text only documents the positive option and its default. Use the explicit form in notes and scripts so the scope is visible to the next person.

Checkpoint: run both commands for the same repository when a rule seems to come from nowhere. If the default view contains a rule that disappears with --no-parents, track down the organisation or other higher-level source before you touch repository policy.

5. View an organisation-level ruleset

For a ruleset configured at organisation scope, provide the organisation name:

$ gh ruleset view RULESET_ID --org ORGANISATION

Replace RULESET_ID and ORGANISATION with values from your environment. The --org option tells gh how to resolve an organisation-level ID; it is not a permission bypass, and it does not convert a repository ruleset into an organisation ruleset.

If the command reports that the ruleset cannot be found, check the scope first: a repository-level ID and an organisation-level ID are not interchangeable just because they are both numbers. Then check the account selected by gh auth status.

6. Open the ruleset in the browser

Use --web when the web interface is the clearest way to inspect the rule or its surrounding settings:

$ gh ruleset view RULESET_ID --repo OWNER/REPOSITORY --web

This asks gh to open the ruleset in your browser. It is still a viewing operation, but launching a browser is an external side effect and may not work on a headless server or over SSH. Use the terminal form when you need output you can record in an audit.

Do not treat a browser opening successfully as proof the policy was read successfully. Check that the page shows the intended owner and repository, and do not edit or save anything unless that separate change is authorised. If you opened the wrong page, close the tab; no GitHub configuration needs undoing by the command itself.

7. Diagnose failures without changing policy

Rerun the command with an explicit repository or organisation and a known ID first. A missing or mistyped ID, wrong scope, unavailable network, insufficient GitHub permission, and expired authentication can all look similar at a glance.

$ gh auth status
$ gh ruleset view RULESET_ID --repo OWNER/REPOSITORY
$ printf 'exit status: %s\n' "$?"

For an authenticated request, exit status 0 means the command completed successfully. The manual also defines 1 for an error, 2 for a cancelled command, and 4 when authentication is required. A non-zero status is a reason to inspect the error and scope, not to retry with sudo.

When no ID is supplied, cancelling the interactive chooser is distinct from a successful view. In automation, avoid the chooser and capture the exit status of an explicit invocation. If you need a machine-readable inventory rather than one selected ruleset, stop and use a command meant for listing rulesets; do not scrape a prompt.

Done means