# kubectx: Switch Kubernetes Contexts Fast

> kubectx switches between kubeconfig contexts, lists them, and jumps back with the - shortcut. Reference for select, rename, current, and CI errors.

Source: https://latchkey.dev/learn/command-reference/kubectx-switch  
Updated: 2026-06-30

kubectx <name> sets the current context, kubectx with no argument lists them, and kubectx - switches back to the previous one.

Typing `kubectl config use-context` over and over is tedious. kubectx is a one-word switch with tab completion and a back button.

## What it does

kubectx is a thin wrapper over the kubeconfig `current-context`. With an argument it switches; with none it lists all contexts and highlights the active one; `-` toggles to the previous context, like `cd -`.

## Common usage

```Terminal
kubectx                       # list contexts, current one highlighted
kubectx staging               # switch to the staging context
kubectx -                     # back to the previous context
kubectx prod=arn:aws:eks:...  # alias a long context name to "prod"
```

## Options

| Form | What it does |
| --- | --- |
| kubectx | List all contexts |
| kubectx <name> | Switch to that context |
| kubectx - | Switch to the previous context |
| kubectx -c, --current | Print the current context name only |
| kubectx <new>=<old> | Rename / alias a context |
| kubectx -d <name> | Delete a context from kubeconfig |

## In CI

In a job that touches several clusters, set `KUBECONFIG` to a merged file and use `kubectx <name>` before each step. Prefer `kubectx -c` over parsing `kubectl config current-context` when you just need the name.

## Common errors in CI

`error: no context exists with the name: "staging"` means the context is absent from the active KUBECONFIG; run `kubectx` to see the real names. `kubectx -` printing `error: no previous context found` happens on the first switch in a fresh shell, where no prior context was recorded.

## Using this in CI

A runner has no kubeconfig, no cached context, and no interactive auth. Every kubectl invocation in CI needs the context supplied explicitly, and most confusing CI failures here are the command running against the wrong cluster or no cluster at all.

```Terminal
# never rely on the ambient context on a runner
kubectl --context "$KUBE_CONTEXT" -n "$NAMESPACE" get pods

# confirm what you are actually connected to before mutating anything
kubectl config current-context
kubectl cluster-info

# fail fast instead of hanging on an unreachable API server
kubectl --request-timeout=30s get nodes
```

> Always set `--request-timeout` in CI. Without it an unreachable API server hangs until the job times out, which turns a thirty-second failure into a twenty-minute one.

## FAQ

### kubectx: Switch Kubernetes Contexts Fast?

Typing kubectl config use-context over and over is tedious. kubectx is a one-word switch with tab completion and a back button.

### What it does?

kubectx is a thin wrapper over the kubeconfig current-context. With an argument it switches; with none it lists all contexts and highlights the active one; - toggles to the previous context, like cd -.

### In CI?

In a job that touches several clusters, set KUBECONFIG to a merged file and use kubectx <name> before each step. Prefer kubectx -c over parsing kubectl config current-context when you just need the name.

### Common errors in CI?

error: no context exists with the name: "staging" means the context is absent from the active KUBECONFIG; run kubectx to see the real names. kubectx - printing error: no previous context found happens on the first switch in a fresh shell, where no prior context was recorded.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt