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.

```text
$ 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:
   ```bash
   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.