Enter a context, get a shell locked to it via a private kubeconfig. Every kube tool in that shell sees only that one context.
Zero global mutation
Never touches ~/.kube/config or your active context. Run prod and dev side by side in different terminals with no leakage between them.
Exit = gone
The temp kubeconfig is deleted on exit, whether normal, signal, or crash (a stale-file sweep reaps anything left by a kill -9).
Auth-agnostic
Assumes your contexts are already authenticated. exec/OIDC/cloud plugins keep working; kush copies the user block verbatim.
Works with any tool
kubectl, helm, k9s, kustomize, flux, argocd, and anything else that reads KUBECONFIG is pinned to the one context.
Built for agents too
kush exec runs one command in an isolated context non-interactively, with a Claude Code plugin so agentic tools use it correctly.
Manual juggling vs. kush
How you switch contexts today, and how kush does it
The manual way
Fragile, global, easy to get wrong
•
kubectl config use-context
Mutates global state shared by every shell and tool
•
Per-tool --context flags
Different spelling per tool; forget one and you hit the wrong cluster
•
KUBECONFIG juggling
Hand-built single-context files, easy to misconfigure
•
Leaky by default
The full kubeconfig stays visible to every command
•
Manual cleanup
Temp files and switched contexts linger
The kush way
Isolated, ephemeral, blast-radius-contained
•
kush <ctx>
A subshell pinned to one context; exit and it's gone
•
One uniform form
Every tool in the shell sees exactly one context
•
Private throwaway kubeconfig
Built for you, 0600, in $XDG_RUNTIME_DIR
•
Cannot touch other clusters
The command physically only sees the pinned context
•
Auto-cleanup + stale sweep
Deleted on exit; crashes reaped on next run
Enter a real kind-backed prod context
Loading recording...
That's the whole workflow: enter, work, exit. Nothing you did in there touched ~/.kube/config or your default context; open a second terminal and run kush dev alongside it, zero bleed between the two.
