Transfer a GitHub Issue Safely with gh issue transfer

You will move one GitHub issue to another repository using the installed GitHub CLI command, while checking the source repository and destination before the change. Allow about ten minutes. You need gh installed, an authenticated GitHub account, access to both repositories, and permission to transfer the issue.

The examples use gh 2.87.3, installed here from the gh package. The local manual is dated March 2026. Check your own version first because GitHub CLI behaviour and server permissions can change.

1. Confirm the command and your account

Check the binary and version. This is read-only and does not need elevated privileges:

$ command -v gh
/home/linuxbrew/.linuxbrew/bin/gh
$ gh --version
gh version 2.87.3 (2026-02-23)

Check authentication before you prepare a transfer. Do not paste a token into a command, a shell history file or this guide:

$ gh auth status
github.com
  Logged in to github.com account YOUR_ACCOUNT
  ...

Your account name and the exact status text will differ. If the command reports that you are not logged in, use your normal organisational authentication process. Do not use sudo; elevated local privileges do not grant GitHub repository access.

Checkpoint: continue only when gh auth status identifies the account you intend to use and that account can access both repositories.

2. Read the command shape

The command takes either an issue number or an issue URL, followed by the destination repository:

$ gh issue transfer {<number> | <url>} <destination-repo> [flags]

For the usual case, the destination is written as OWNER/REPO. The inherited -R or --repo option selects the source repository in [HOST/]OWNER/REPO form. It does not select the destination. That distinction is the easiest way to transfer the wrong issue, so make both repositories visible in your notes before running anything.

Inspect the local syntax whenever you are unsure:

$ gh issue transfer --help
Transfer issue to another repository

USAGE
  gh issue transfer {<number> | <url>} <destination-repo> [flags]

INHERITED FLAGS
      --help                     Show help for command
  -R, --repo [HOST/]OWNER/REPO   Select another repository using the [HOST/]OWNER/REPO format

3. Inspect the issue without changing it

Use gh issue view to confirm the issue number, title and source repository. Replace every uppercase placeholder with a real value:

$ SOURCE_REPO='YOUR_ORG/source-repo'
$ ISSUE_NUMBER='123'
$ DESTINATION_REPO='YOUR_ORG/destination-repo'
$ gh issue view "$ISSUE_NUMBER" --repo "$SOURCE_REPO"
Issue #123 in YOUR_ORG/source-repo
Example title
...

The displayed title is your checkpoint. Stop if the number, repository or issue title is not exactly the one you meant to move. A shell variable is only a convenience: it does not validate the repository names or protect you from choosing the wrong account.

If you prefer an unambiguous issue URL, the transfer command also accepts one:

$ gh issue transfer 'https://github.com/YOUR_ORG/source-repo/issues/123' "$DESTINATION_REPO"

Do not run that line yet if you are still checking the target. The command changes GitHub state.

4. Warn before transferring

Transferring an issue is a repository-side change, not a local copy. Treat it as disruptive to anyone using the issue URL, automation or project workflows. The command has no documented dry-run, confirmation flag or undo subcommand in the installed manual.

Before proceeding, record the source repository, issue number, destination repository and current title. Check any repository-specific policy for labels, milestones, projects, links and automation. If the transfer is part of a live incident or release process, coordinate with the people watching that issue first.

There is no local rollback command to include here. If the transfer was wrong, use GitHub's supported issue-management workflow or contact a repository administrator. Do not try the command again as a guessed reversal: its destination argument always means the repository to which you are sending the issue.

5. Transfer the issue

After the checkpoint, run one of these ordinary, unprivileged commands. Use the number form when you have already selected the source with --repo:

$ gh issue transfer "$ISSUE_NUMBER" "$DESTINATION_REPO" --repo "$SOURCE_REPO"
Transferred issue ...

The final message is server- and version-dependent, so treat the command's exit status as the first local signal. A zero exit status means the CLI completed the request; it does not replace checking GitHub. If the command returns an error, keep the output and do not blindly retry. Confirm whether the issue moved before making another request.

The URL form makes the source explicit and is useful when you are working across several repositories:

$ gh issue transfer \
    'https://github.com/YOUR_ORG/source-repo/issues/123' \
    'YOUR_ORG/destination-repo'

Do not combine an issue URL from one repository with a different source selected by --repo. Pick one clear source reference for each invocation.

6. Verify the result

Use the destination issue number or URL shown by GitHub, if the response provides one, to inspect the moved issue:

$ gh issue view NEW_ISSUE_NUMBER --repo "$DESTINATION_REPO"
Issue #NEW_ISSUE_NUMBER in YOUR_ORG/destination-repo
Example title
...

If the number was preserved, you can try "$ISSUE_NUMBER". If it was not, use the destination URL or number from the response and do not assume that the old number applies. You can also open the destination repository in GitHub's web interface and check the title and discussion there.

For a failure, inspect both repositories before retrying:

$ gh issue view "$ISSUE_NUMBER" --repo "$SOURCE_REPO"
$ gh issue list --repo "$DESTINATION_REPO" --search 'Example title'

Search terms can match more than one issue. Confirm the repository and title, not just the first result. If access, organisation policy or an issue state prevents the transfer, fix that condition or ask an administrator rather than escalating local privileges.