cli/cli · error

label with name %q already exists

Error message

label with name %q already exists

What it means

Thrown by `gh label edit` when renaming a label to a name that already exists. updateLabel returns the sentinel errLabelAlreadyExists (GitHub rejects a rename onto an existing label name), and the command surfaces it naming opts.NewName, the requested new name.

Source

Thrown at pkg/cmd/label/edit.go:92

func editRun(opts *editOptions) error {
	httpClient, err := opts.HttpClient()
	if err != nil {
		return err
	}
	apiClient := api.NewClientFromHTTP(httpClient)

	baseRepo, err := opts.BaseRepo()
	if err != nil {
		return err
	}

	opts.IO.StartProgressIndicator()
	err = updateLabel(apiClient, baseRepo, opts)
	opts.IO.StopProgressIndicator()
	if err != nil {
		if errors.Is(err, errLabelAlreadyExists) {
			return fmt.Errorf("label with name %q already exists", opts.NewName)
		}
		return err
	}

	if opts.IO.IsStdoutTTY() {
		cs := opts.IO.ColorScheme()
		successMsg := fmt.Sprintf("%s Label %q updated in %s\n", cs.SuccessIcon(), opts.Name, ghrepo.FullName(baseRepo))
		fmt.Fprint(opts.IO.Out, successMsg)
	}

	return nil
}

View on GitHub (pinned to 0eeec0b92e)

Solutions

  1. Pick a new name that no label currently uses; list candidates first with `gh label list --json name --jq '.[].name'`.
  2. If the goal is merging labels, delete the target label first (`gh label delete <new-name> --yes`) then run the edit.
  3. For case-only renames, first rename to a temporary name, then to the desired casing.

Example fix

# before
gh label edit "help wanted" --name "good first issue"
# error: label with name "good first issue" already exists

# after
gh label delete "good first issue" --yes
gh label edit "help wanted" --name "good first issue"
Defensive patterns

Strategy: validation

Validate before calling

# before renaming, ensure the target name is free
existing=$(gh label list --json name --jq '.[].name' | grep -ixF "$new_name" || true)
[ -n "$existing" ] && { echo "label '$new_name' taken" >&2; exit 2; }
gh label edit "$old_name" --name "$new_name"

Prevention

When it happens

Trigger: Calling `gh label edit <old-name> --name <new-name>` where <new-name> (case-insensitive) is already taken by another label in the repository. Also triggered when --name is omitted... only if opts.NewName collides; in practice it fires on rename collisions detected by the API.

Common situations: Label taxonomy cleanups that merge two labels by renaming one onto the other; automation that 'normalizes' label casing ('Bug' -> 'bug' when 'bug' exists); partial migrations re-run after failure.

Related errors


AI-assisted analysis of cli/cli@0eeec0b92e (2026-08-15). Data as JSON: /api/errors/10db0f4c21f2ec5c. Report an issue: GitHub.