kubectx and kubens: switching kubectl contexts and namespaces without editing kubeconfig

The problem: kubeconfig switching is verbose and stateful

kubectl stores the active context and namespace in your kubeconfig file, so every switch is a write to that file through a long subcommand. Changing cluster means `kubectl config use-context`, and changing namespace means `kubectl config set-context --current --namespace=<name>`. Neither is hard to type once. Both are annoying when you alternate between a staging cluster and a production cluster ten times an hour, and neither gives you a way back to the previous value.

kubectx and kubens are wrappers that exist purely to shorten that loop. The README describes kubectx as "a tool to switch between contexts (clusters) on kubectl faster" and kubens as a tool to "switch between Kubernetes namespaces (and configure them for kubectl) easily". They are for engineers who already have a populated kubeconfig and want the switch itself to cost three keystrokes. They are not for creating clusters, creating contexts, or managing credentials.

How kubectx and kubens actually work

The repository ships a Go implementation under `cmd/` and `internal/`, with `kubectx` and `kubens` at the top level and completion scripts in `completion/`. The module imports `k8s.io/client-go` and `k8s.io/apimachinery`, which is the client library kubectl itself is built on, so the tools read and write kubeconfig through the same code path rather than by parsing YAML by hand. The `go.mod` also pulls in `facette.io/natsort` for natural ordering of context names and `github.com/fatih/color` for the highlighted current entry.

That design has a visible consequence. Because the tools operate on the kubeconfig file, a switch is a persistent change to shared state: run `kubectx staging` in one terminal and the next `kubectl` command in a different terminal uses staging too. The README addresses this with two flags, `kubectx -s <context>` for "an isolated shell that only has a single context" and `kubectx -r <context>` for "a read-only shell where write operations are blocked". Those are the escape hatches from the shared-state model, and they are the reason the tool is more than an alias.

Namespace handling is separate. kubens sets the namespace on the current context, so switching context and switching namespace are independent operations. The README notes that `kubens -` returns to the previous namespace and that `-f` forces a namespace that does not exist yet.

Installing kubectx on Linux, macOS and Windows

The README lists package managers for every major platform. On macOS and Linux, Homebrew is the shortest route. On Debian and Ubuntu the package is in apt, and Arch users get it from pacman. Windows has three options: Chocolatey, Scoop and winget. If you already use the krew plugin manager for kubectl, the README gives `kubectl krew install ctx` and `kubectl krew install ns`, which installs the same tools as kubectl plugins named `ctx` and `ns`.

brew install kubectx

On Debian or Ubuntu the equivalent is:

sudo apt install kubectx

Windows users can use winget, which installs the two tools as separate packages:

winget install --id ahmetb.kubectx && winget install --id ahmetb.kubens

The README also points to the Releases page for standalone binaries that you place somewhere on your `PATH`. After installing, `kubectx` with no arguments prints the contexts in your kubeconfig and marks the current one; that output is the confirmation that the binary found your kubeconfig at all.

A first real switch, and the fzf behavior that surprises people

The basic flow is one argument. The README's example switches to a context named minikube and prints a confirmation:

kubectx minikube

The documented output is `Switched to context "minikube".` From there, `kubectx -` returns to the context you came from. Namespaces work the same way, with the current context named in the output:

kubens kube-system

The README shows this printing `Context "test" set.` followed by `Active namespace is "kube-system".` If the namespace does not exist yet and you want to set it anyway, `kubens namespace-404 -f` forces it.

Interactive mode is where the tool changes character. If `fzf` is anywhere on your `PATH`, running `kubectx` or `kubens` with no arguments opens a fuzzy-searchable menu instead of printing a list. The README documents two ways to control this: set `KUBECTX_IGNORE_FZF=1` to opt out entirely, or pipe the output to another command, for example `kubectx | cat`, to get the non-interactive behavior while keeping fzf installed. That second rule is worth remembering, because a script that calls `kubectx` and expects a list will hang on a menu on any machine where fzf happens to be installed.

Where kubectx and kubens are the wrong tool

The shared kubeconfig is the main limitation, and it is structural rather than a bug. Every switch mutates a file that all of your terminals read. If you want two shells pointed at two different clusters at the same time, kubectx alone does not give you that; you need the `-s` isolated shell or a tool built around per-shell context, which is a different architecture.

There is also a gap between the flags. `kubectx -r` blocks write operations in an isolated shell, but the README does not describe a read-only mode for the current shell without isolation, and it does not document rollback of a context or namespace change beyond the `-` shortcut, which remembers one previous value, not a history. If you rename a context by mistake, `kubectx dublin=gke_ahmetb_europe-west1-b_dublin` renames it back only if you remember the original generated name.

Finally, the README does not document any behavior for kubeconfigs assembled from multiple files through `KUBECONFIG`. Whether a switch writes to the first file in the list or to a merged view is not stated, so treat that as something to verify against your own setup before relying on it.

kubectx vs kubie, k9s and plain kubectl

The honest comparison is with tools that solve an adjacent problem. Plain kubectl is not an alternative so much as the thing kubectx wraps: `kubectl config use-context` does the same write, and kubectx adds the `-` shortcut, the isolated and read-only shells, colored output, and the fzf menu. If none of those matter to you, an alias is enough.

kubie appears in search queries alongside kubectx, and the architectural difference is the shell. kubie is built around spawning a subshell with its own context, so two terminals can hold two different clusters at once. kubectx defaults to mutating the shared kubeconfig and offers `-s` as an opt-in isolated shell, which is the opposite default. If your workflow is genuinely parallel across clusters, that default matters more than command length.

k9s is a different category: a terminal UI for browsing and operating on resources inside a cluster. It can switch contexts, but switching is a side effect of a broader interface. kubectx and kubens do one thing and exit, which is why they compose well with shell prompts and scripts. The README itself recommends pairing them with fzf and kube-ps1 rather than treating them as a full interface.

Maintenance, licensing and upgrade cost

The repository is not archived, and its last push was on 2026-03-27, which is the same date as the v0.11.0 release. The two releases before it, v0.10.2 and v0.10.0, landed in the same week, so the recent release cadence is a burst rather than a steady drumbeat. The README contains a note that the stargazers chart is broken since August 2021, which is a small sign of how much attention the surrounding documentation gets.

The project is Apache-2.0, which permits commercial use and modification provided the license and notices are preserved; that is a summary of the identifier, not legal advice, and you should read the LICENSE file in the repository if the distinction matters to your organization.

Upgrade cost is low by design. The tools are stateless binaries with no server component and no configuration file of their own; the only persistent state they touch is your kubeconfig. Package manager installs update with the rest of your system, and the krew route updates with `kubectl krew upgrade`. The one thing to re-check after an upgrade is shell completion, since the README documents separate completion scripts for bash, zsh and fish that are installed by hand or through a plugin manager, not by the package itself.

Editorial conclusion

Adopt kubectx and kubens if you work across several clusters or namespaces from one machine and you are tired of typing kubectl config use-context and full namespace flags. Skip them if you need simultaneous, isolated contexts in one terminal session, or if you want a full terminal UI for cluster resources: they do not provide either. Before installing, check that your kubeconfig already has the contexts you need, since neither tool creates them, and confirm whether fzf is on your PATH, because that single fact decides whether kubectx opens a picker or prints a list.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes