kush exec runs a single command against an isolated context, non-interactively, with no subshell, no picker, and nothing waiting on a TTY. It's the form to reach for from scripts, CI, and agents.

The command

kush exec <context> [-n namespace] -- <command> [args...]

Everything after -- is the command to run. kush pins KUBECONFIG to a private one-context temp file for the duration of that command, forwards stdin/stdout/stderr, propagates the child's exit code, and deletes the temp file when the command finishes:

Run one command without entering a shell

Targeting a namespace

Pass -n/--namespace to pin the namespace for that one command:

Run against a specific namespace

$ kush exec prod -n billing -- kubectl get pods
NAME                READY   STATUS    RESTARTS   AGE
worker-6f9c7d-abcde  1/1     Running   0          2h

Exit codes and stdio are forwarded

kush exec is transparent to the command it runs: stdout and stderr pass straight through, and the process exits with the same code the wrapped command did. A failing command still fails the kush exec call:

Exit code propagation

$ kush exec staging -- kubectl get pod does-not-exist
Error from server (NotFound): pods "does-not-exist" not found

$ echo $?
1

That makes it safe to chain in a script with && or check in CI without any extra plumbing.

Works with any tool

kush exec isn't kubectl-specific; it works with anything that reads KUBECONFIG:

helm through kush exec

$ kush exec staging -n billing -- helm upgrade --install billing ./chart
Release "billing" has been upgraded. Happy Helming!

Use in scripts and CI

Because each invocation is a single non-interactive process with a temp kubeconfig cleaned up on exit, kush exec composes cleanly in scripts:

In a CI step

$ kush exec prod -n billing -- kubectl rollout status deploy/billing
deployment "billing" successfully rolled out

$ kush exec prod -- kubectl get nodes -o name | wc -l
5

The agent-safe alternative

kush ctx and kush ns are interactive; they wait for a shell to exit, which will hang an agent or a non-interactive CI runner that doesn't know to send an exit. kush exec never spawns a shell and never waits on anything beyond the one command you gave it, which makes it the form to use whenever the caller isn't a human at a terminal.

It also beats kubectl --context for that use case: it's uniform across every kube tool, not just kubectl, and it gives real blast-radius containment. The command physically cannot see or touch any context other than the one you named, because no other context exists in the temp kubeconfig it's handed.

Edit this page