Troubleshoot the 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 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:

  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.

Last updated on