Unable to connect to api server - k9s context "[name]" does not exist

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

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.

1. Select the correct context.

Expected: k9s connects and resources load.

1. Or list them from the shell:

kubectl config get-contexts

Expected: Shows the valid names to type.

1. 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