# Troubleshoot the CLI (https://developer.godaddy.com/en/docs/api-users/troubleshoot/cli)

---
title: Troubleshoot the CLI
description: >-
  Common errors when installing or using the GoDaddy CLI (gddy), with causes and
  resolutions.
keywords: >-
  command not found gddy, PATH ~/.local/bin, %LOCALAPPDATA% Programs gddy, OAuth
  redirect localhost, Gatekeeper macOS blocked binary, Set-ExecutionPolicy
  PowerShell, gddy auth status, install.sh permission denied
agentNotes:
  scopes:
    - N/A — CLI handles auth internally
  rateLimit: N/A (diagnostic reference)
  failureRecovery: >-
    Diagnostic page. For PATH issues, open a new terminal. For auth issues, run
    'gddy auth login'. For permission errors, check OS security settings. CLI
    targets one environment at a time — verify with 'gddy auth status'.
faqItems:
  - question: 'Why does ''command not found: gddy'' appear after installation?'
    answer: >-
      Your PATH doesn't include the directory where the CLI was installed. In a
      terminal window, verify the binary exists at ~/.local/bin/gddy (or
      %LOCALAPPDATA%\Programs\gddy on Windows), and add the bin directory to
      PATH if needed.
  - question: Why does 'gddy auth login' open a browser but nothing happens?
    answer: >-
      The browser can't complete the OAuth redirect back to the CLI's local
      listener. Ensure you're not in a headless environment, try copying the URL
      manually, check for proxy interference with localhost, or try a different
      browser.
  - question: Why does 'gddy domain suggest' return an authentication error?
    answer: >-
      Authentication hasn't been configured or the saved token has expired. Run
      'gddy auth status' to check, then 'gddy auth login' to re-authenticate if
      needed.
  - question: Why does the CLI installer fail with a permission error?
    answer: >-
      The script can't write to the target directory, or macOS Gatekeeper is
      blocking the binary. The installer defaults to ~/.local/bin (macOS/Linux)
      or %LOCALAPPDATA%\Programs\gddy (Windows), both user-writable, and falls
      back to sudo automatically on macOS/Linux only if that directory isn't
      writable. On macOS, allow in Security & Privacy settings if Gatekeeper
      blocks the binary. On Windows, no elevation should be needed unless you
      passed a system-owned --prefix.
  - question: Why do CLI commands return different results than curl?
    answer: >-
      The CLI might be using different credentials than your curl commands.
      Check with 'gddy auth status' and re-authenticate if needed.
related:
  guides:
    - title: Set up the CLI
      href: /docs/api-users/cli/set-up
    - title: CLI reference
      href: /docs/api-users/cli/reference
    - title: Troubleshoot authentication
      href: /docs/api-users/troubleshoot/authentication
    - title: Make your first call
      href: /docs/api-users/quickstart
---

## Overview

This page covers errors you may encounter when installing, authenticating, or using the `gddy` CLI. If you're setting up for the first time, go to [Set up the CLI](https://developer.godaddy.com/docs/api-users/cli/set-up) for the installation guide. If a command itself is throwing an error, check the [CLI reference](https://developer.godaddy.com/docs/api-users/cli/reference) to confirm you're using the right flags.

## `command not found: gddy`

**Symptom:** Running `gddy` returns "command not found" or "not recognized" after installation.

**Cause:** Your PATH does not include the directory where the CLI was installed.

**Resolution:**

* **Windows:** `install.ps1` adds the install directory to your user `PATH` automatically, but only new terminal sessions pick up the change — open a new terminal and try again.
* **macOS/Linux:** `install.sh` does not modify your `PATH`. Add the bin directory manually, then add the same line to your shell profile (e.g. `~/.zshrc` or `~/.bashrc`) to persist it:
  ```bash
  export PATH="$HOME/.local/bin:$PATH"
  ```
* Verify the binary exists: `ls ~/.local/bin/gddy` (macOS/Linux) or check `%LOCALAPPDATA%\Programs\gddy\` (Windows).
* Re-run the installer if the binary doesn't exist.

## `gddy auth login` opens a browser but nothing happens

**Symptom:** The CLI opens a browser tab for OAuth login, but the redirect fails or hangs.

**Cause:** The browser can't complete the OAuth redirect back to the CLI's local listener.

**Resolution:**

* Make sure you're not in a headless/SSH environment without browser access.
* If the browser opened but the page failed to load, copy the URL from the terminal output and paste it manually.
* If behind a corporate proxy, the redirect URL (`localhost`) may be intercepted — check with your network team.
* Try a different browser if the default one has strict security extensions blocking localhost redirects.

## `gddy domain suggest` returns an authentication error

**Symptom:** Running domain commands returns an auth-related error.

**Cause:** Authentication hasn't been configured, or the saved token has expired.

**Resolution:**

* Run `gddy auth status` to check whether you're authenticated and which environment you're targeting.
* If expired or not authenticated, run `gddy auth login` to re-authenticate.
* If targeting the wrong environment, use `gddy auth login --env prod` (or `--env ote`) to specify.

## Installer fails with a permission error

**Symptom:** The install script exits with "Permission denied" or similar.

**Cause:** The script can't write to the target directory, or macOS Gatekeeper is blocking the binary.

**Resolution:**

* The installer defaults to `~/.local/bin` (macOS/Linux) or `%LOCALAPPDATA%\Programs\gddy` (Windows) — both are user-writable, so this shouldn't come up on a default install.
* On macOS: if you see "cannot be opened because the developer cannot be verified," go to System Preferences → Security & Privacy → General and click "Allow Anyway."
* On Linux: if you passed a `--prefix` pointing at a directory you don't own (e.g. `/usr/local/bin`), the installer falls back to `sudo` automatically.
* On Windows PowerShell: if the execution policy blocks running the remote script via `iex`, run `Set-ExecutionPolicy -Scope Process Bypass` for the session, or download `install.ps1` and inspect it before running.

## CLI commands work but return different results than curl

**Symptom:** The CLI returns different data or errors compared to the same operation via curl.

**Cause:** The CLI might be using different credentials than your curl commands.

**Resolution:**

* Check your current environment: `gddy auth status`
* If targeting the wrong environment, re-authenticate against the correct one.
* Compare the base URL: CLI uses the environment from its auth config, while curl hits whatever URL you specify directly.