vultr-cli works as your user but 401s under sudo

sudo switches to root's home, where your CLI config does not exist. Pass the key through explicitly: sudo VULTR_API_KEY [your value] vultr-cli ..., or stop using sudo for API calls (it is not needed). The key is fine; root just cannot see your config file.

$ vultr-cli account get        # works
$ sudo vultr-cli account get
{"error": "Invalid API key", "status": 401}

Fix

1. Confirm the split: run the same command with and without sudo and compare.

2. Pass the key through sudo's environment:

   sudo VULTR_API_KEY [your value] vultr-cli account get

   Expected: works, same as unprivileged.

3. Better: drop sudo entirely for API calls. vultr-cli talks to a remote API; it never needs root.
4. If some wrapper truly requires root, configure root's own CLI config once (sudo -i, then set up the key there).

When this applies

• Commands work as your user, 401 as root or another user.
• Cron/systemd jobs running as a different user than the one that configured the CLI.

When it does NOT apply

• 401 as your own user too: the key itself is bad.
• 403s: permissions or user-level API gating.

Compatibility

• vultr-cli on Linux/macOS with per-user config files.

Why it happens

Config resolution is per-UID: ~/.vultr-cli.yaml expands against the invoking user's home. sudo (without -E and env preservation rules) gives the process root's home, so the CLI finds no key and 401s. Nothing about the key changed; the file lookup did.

Edge cases

• sudo -E preserves the environment but many sudoers configs strip custom vars; explicit VAR=value sudo is more reliable.
• Systemd units: put the key in the unit's Environment= or an EnvironmentFile= readable by the service user.
• Docker: bake nothing; pass -e VULTR_API_KEY at run time.

vultr-cli reads its configuration from the invoking user's home directory (~/.vultr-cli.yaml), the standard XDG-style per-user config pattern shared by doctl, linode-cli, and hcloud. Running under sudo switches HOME to /root, so the CLI reads root's (nonexistent or different) config and reports 401. The same class of per-user-config surprise is documented across these CLIs; the fix is to make the credential available to the elevated process explicitly, e.g. 'sudo VULTRAPIKEY [your value] vultr-cli ...' or configuring root's own config. This is a config-resolution problem, not a key problem.