You asked k9s for a context name that is not in your kubeconfig - usually a typo in the :ctx command - so k9s has nothing to connect to. Type :ctx with no argument to see the real list, pick the right name, and k9s connects. If the context genuinely vanished, re-fetch your kubeconfig from the provider.

## The error
```text
Unable to connect to api server error="context \"prod-typo\" does not exist"
```

## What to do
1. In k9s, type `:ctx` and hit enter.
   Expected: The context picker lists the available contexts.
2. Select the correct context.
   Expected: k9s connects and resources load.
3. Or list them from the shell:
```bash
kubectl config get-contexts
```
   Expected: Shows the valid names to type.
4. If your context is really gone, regenerate the kubeconfig (aws eks update-kubeconfig, gcloud get-credentials, ...).
   Expected: Context reappears in the list.

## When this applies
- the exact context does not exist message in k9s
- typos in the :ctx command
- contexts removed by a kubeconfig regeneration

## When it does NOT apply
- valid context with bad credentials (different error)
- k9s can not find any kubeconfig at all

## Works with
k9s all versions

### error: context "[name]" does not exist (kubectl)
kubectl's wording for the same typo. Same fix: use-context with a real name.

## Why it happens
k9s switches its client to whatever context name you give it without validating first. A name that matches nothing leaves the client with no cluster to dial, and it reports the missing name.

## Edge cases
- KUBECONFIG with several files merges contexts - a name can exist in one file and vanish when that file's path breaks.
- After get-credentials rewrites, old context names may be renamed; re-list before assuming a typo.

## Resolved from
gh:derailed/k9s#539 - https://github.com/derailed/k9s/issues/539