That token belongs to a different project. Hetzner tokens are project-scoped, so the 'missing' resources were never visible to this token. Create one context per project, each with that project's token, and switch with `hcloud context use`.

```text
$ hcloud server list
# empty - but the console shows 4 servers (they live in project B; this token is project A's)
```

## Fix

1. In the console, open the project you actually want and create an API token there (project, Security, API Tokens).

2. Create a context for it:
   ```bash
   hcloud context create project-b
   ```
   Paste project B's token. Expected: context created and activated.

3. Switch between projects explicitly:
   ```bash
   hcloud context use project-a
   hcloud context use project-b
   ```

4. Verify:
   ```bash
   hcloud context active && hcloud server list
   ```
   Expected: the intended project's servers.

## When this applies
- Resource lists are unexpectedly empty or show unfamiliar resources.
- You manage several Hetzner projects with one CLI.

## When it does NOT apply
- 401: the token itself is dead.
- 404 on a specific resource: wrong name/ID within the right project.

## Compatibility
- hcloud CLI v1.x.

## Why it happens
Project scoping is enforced server-side per token, and the CLI never warns that the token's project differs from the one you have in mind. The commands succeed, so there is no error to debug - just the wrong inventory.

## Edge cases
- Name contexts after projects (`prod`, `staging`) so `hcloud context list` is self-documenting.
- In automation, one `HCLOUD_TOKEN` per job removes all ambiguity; contexts are for interactive use.
- Deleting a project invalidates its tokens; the context then 401s until recreated.