Shells and terminals · New in v0.3.0

A shell in a container, on a node, inside the cluster, or on your machine

PodSteer opens five kinds of shell: into a container, into an ephemeral debug container, onto a node's host, inside the cluster's network, and on your own machine with the tab's context already selected. Every pod it creates for one is deleted when the shell closes.

The five shells

  • Exec into any container, or attach to its main process.
  • An ephemeral debug container in a pod you are investigating — the equivalent of kubectl debug.
  • A node shell: a privileged pod entering the node's host namespaces, deleted when the terminal closes or PodSteer quits, with a one-hour backstop.
  • An in-cluster shell: an unprivileged throwaway pod that runs under Pod Security's restricted profile, so kubectl, dig and curl run from inside the cluster.
  • A local terminal: your own login shell, with the tab's context selected — on macOS, Linux and Windows.
A payments-api pod's detail panel on its Terminal tab, connected to a shell that has printed the pod's version, memory limit and namespace from its environment, looked up a Service's address through cluster DNS, and fetched a page from it. A payments-api pod's detail panel on its Terminal tab, connected to a shell that has printed the pod's version, memory limit and namespace from its environment, looked up a Service's address through cluster DNS, and fetched a page from it.
A shell in a pod. A shell into the container from the pod's own panel, with the pod list still beside it.

Your kubeconfig is not rewritten

The local terminal selects the tab's context through a tiny kubeconfig of its own, placed first and deleted when the terminal closes. Your own file is read, never written, and kubectl in your other terminals keeps its target.

Files and reachability

  • Copy files to and from a container, and browse its filesystem — unpacked on your machine with path-traversal protection.
  • Probe whether a Service or pod can be reached, from your machine or from inside a container, with DNS, connect and TLS reported as separate steps.
  • Port-forward to a pod or a Service, with remembered ports and a free-port check. A forward that cannot reconnect is shown as Lost, with Reconnect, rather than disappearing.
  • Optionally keep a forward across restarts: it is restored when you reconnect that cluster.

What it does not do.

  • Keeping a port-forward across restarts is off by default and, when ticked, writes its namespace and pod or Service name to settings.json. A Service is the durable choice, because a pod's name changes with every rollout.
  • Nothing is bundled: the local terminal runs the kubectl, helm and agents you already have.
  • Kubernetes never removes an ephemeral container; it stays in the pod's spec until the pod is deleted.
  • Copying needs tar in the container and browsing needs sh; a distroless image can be copied from but not browsed.
  • The shell images are pinned public images you can point at your own registry mirror in Settings.

MCP server and coding agents

podsteer mcp: nineteen read-only tools for Claude Code and other agents, over stdio — no port, no writes, Secret values masked.

Day-2 operations

Apply any kind including CRDs, roll back, drain, bulk-act with a review step — and see the kubectl command for each.

Multi-cluster

Real tabs, one cluster each; one table across every open cluster; clusters found through your own cloud CLI.