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



## 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-setup) for the installation guide.

## `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 production` 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.