Your token is in plaintext in `~/.config/hcloud/cli.toml`; permissions are its only protection. Run `chmod 600 ~/.config/hcloud/cli.toml` and `chmod 700 ~/.config/hcloud`. On shared machines a world-readable config hands your project API access to every other user.

```text
$ ls -l ~/.config/hcloud/cli.toml
-rw-r--r--r 1 you you 312 Oct 2 10:14 [HOME]/...
# ^ readable by everyone on this box; the file contains your API token in plaintext
```

## Fix

1. Lock it down:
   ```bash
   chmod 700 ~/.config/hcloud
   chmod 600 ~/.config/hcloud/cli.toml
   ```
   Expected: `ls -l` shows `-rw-------`.

2. Check your umask for future files: `umask` should be `0077` or `0027` at most on shared boxes.

3. If the file was ever world-readable on an untrusted machine, regenerate the token in the console and recreate the context; assume the old one is compromised.

4. Never commit `cli.toml` to a dotfiles repo; keep a template with a placeholder instead.

## When this applies
- Setting up hcloud on shared servers, lab machines, or containers with multiple users.
- After copying the config between hosts (permissions rarely survive the copy as intended).

## When it does NOT apply
- Auth errors: this is a secrecy issue, not a validity issue.
- Single-user personal laptop with full-disk encryption: nice hygiene, low risk.

## Compatibility
- hcloud CLI v1.x on Linux/macOS.

## Why it happens
The CLI needs the token on every call and stores it as plaintext TOML; there is no OS keychain integration. Convenience wins, so the security boundary is the file mode. Default umasks on many distros (022) create world-readable files unless you tighten them.

## Edge cases
- Backups of home directories copy the token too; encrypt backups or exclude the file.
- In CI, prefer `HCLOUD_TOKEN` from the secrets store over a checked-in config file.
- `hcloud context delete` removes the token from the file; deleting the context is the clean way to decommission a machine.