# How to Show Kubernetes Context in Starship Prompt [2026]

> Build a fast Starship prompt that shows Kubernetes context/namespace safely, profiles slow modules (Git + k8s), and avoids leaking cluster names in demos.

- Canonical: https://www.kunalganglani.com/blog/starship-prompt-kubernetes-context
- Author: Kunal Ganglani
- Published: 2026-08-18 · Updated: 2026-08-18
- Category: Developer Tools · Tags: terminal, starship, kubernetes, developer-productivity, security

## TL;DR

Your terminal prompt can show which Kubernetes cluster you’re about to deploy to. That’s useful. It’s also easy to make slow, noisy, and risky to screen-share. This guide walks you through setting up a Starship prompt that shows Kubernetes context and namespace only when it matters, keeps Git indicators fast in big repos, and avoids leaking internal cluster names in demos. You’ll learn where Starship stores its config and logs, how to validate what Starship shows against kubectl, and how to keep a “recording-safe” prompt you can switch to instantly.

## How to Show Kubernetes Context in Starship Prompt [2026]

I’m not interested in a “pretty” prompt. I want a Starship prompt that (1) shows Kubernetes context + namespace only when it actually helps, (2) stays fast even inside gross monorepos and devcontainer mounts, and (3) doesn’t casually leak your cluster naming conventions on a Zoom recording. Budget 20–30 minutes if you already have Starship installed.

![black flat screen computer monitor](https://cdn.sanity.io/images/vzekdneq/production/099614c88f6c6917dbde4fa5669263c5c1cb1305-1200x675.webp)

This guide is specifically for the "starship prompt kubernetes context" crowd. You’re hopping between multiple clusters, you’ve got a kubeconfig that’s grown barnacles over the years, and your terminal is basically a tiny data-exfiltration surface.

Here’s my opinion, stated plainly: your prompt is UI. UI gets a latency budget and a security budget. If you don’t enforce both, your terminal will feel sluggish, and your demos will accidentally advertise your internal infrastructure.

Here’s the official Starship demo people keep sharing. It’s a good vibe. But “good vibe” is not the same as “safe to use in front of customers.”

Here’s a quick video walkthrough if you want a visual reference:

[Watch: Your shell prompt, ON STEROIDS // Starship](https://www.youtube.com/watch?v=G7aWxK4395Y)

## What is a Starship prompt Kubernetes context?

A Starship prompt Kubernetes context is the active Kubernetes kubeconfig context (and optionally namespace) rendered inside your shell prompt using Starship’s `kubernetes` module.

![Code written on a screen, likely programming related](https://cdn.sanity.io/images/vzekdneq/production/b6c70c135faed179467e40c75291c1c48f7ffb47-1200x675.webp)

Starship pulls the context from your kubeconfig and prints it as part of your prompt format. Kubernetes exposes the same value via `kubectl config current-context`, which is the source of truth you can always sanity-check.

The real question is not “can I display it?” It’s “can I display it without turning my prompt into a 200ms tax and without broadcasting `prod-us-east-1-super-secret` on a screen share?”

## Config file location (and how I keep prompt configs portable)

Starship is configured via `~/.config/starship.toml` by default. The docs are clear about this, including how to create it (`mkdir -p ~/.config && touch ~/.config/starship.toml`) and how to add schema completions using `$schema`.

![text](https://cdn.sanity.io/images/vzekdneq/production/ad8a6c7c8412129845dc716c3d206b34d7c203c9-1200x675.webp)

Two things I’d do immediately:

1) **Add the schema header** so your editor autocompletes module fields instead of making you spelunk docs mid-edit. 2) **Override the config path with `STARSHIP_CONFIG`** so you can swap between a “daily driver” prompt and a “recording safe” prompt.

From the Starship configuration docs, you can override the path like this:

- POSIX shells: `export STARSHIP_CONFIG=~/example/non/default/path/starship.toml`
- PowerShell: set `$ENV:STARSHIP_CONFIG = "$HOME\...\starship.toml"`
(Directly from the official [Starship configuration reference](https://starship.rs/config/#kubernetes).)

My layout looks like this:

- `~/.config/starship/starship.toml` (normal)
- `~/.config/starship/starship-recording.toml` (redacted)
Then in my shell profile:

- `STARSHIP_CONFIG=~/.config/starship/starship.toml`
And when I’m recording:

- `STARSHIP_CONFIG=~/.config/starship/starship-recording.toml`
The exact paths don’t matter. What matters is the behavior. **You should be able to flip modes in two seconds without thinking.**

If you already do reproducible terminal setups with `direnv` or `mise`, you can scope this per-project too. I’ve got a longer workflow write-up in [Reproducible Terminal Dev Environment](/blog/reproducible-terminal-dev-environment).

## Prompt profiling loop: baseline → isolate slow modules → fix or cut

Most Starship setups go off the rails because people treat prompt config like aesthetics. I treat it like a performance budget.

### Step 1: Establish a baseline (repeatably)

Measure in a directory that represents your worst case:

- a monorepo with a lot of untracked files
- a repo with submodules
- a mounted filesystem (devcontainer bind mount, NFS, etc.)
Then do three quick passes so you’re not chasing random variance:

1. Open a fresh terminal tab
1. `cd` into the repo
1. Hit Enter 20–30 times
If the prompt is slow, you won’t need a benchmark to notice. Human-perceived latency starts getting annoying around **100ms**. At **200ms+**, it’s not “subtle.” It’s the terminal feeling sticky.

### Step 2: Use Starship’s own logs as your “what just happened?” trace

By default, Starship logs warnings and errors to `~/.cache/starship/session_${STARSHIP_SESSION_KEY}.log`. That’s not hearsay. It’s in the official docs under Logging, including how to move the cache directory with `STARSHIP_CACHE`.

- Default: `~/.cache/starship/session_${STARSHIP_SESSION_KEY}.log`
- Override: `export STARSHIP_CACHE=~/.starship/cache`
Source: [Starship configuration docs](https://starship.rs/config/#kubernetes).

Two practical uses for this file:

- **Debugging:** when a module is erroring or timing out, this is often where it shows up.
- **Security hygiene:** if you printed something sensitive in your prompt, it can end up here depending on how the module fails.
I treat prompt logs like app logs. If I wouldn’t want a token in application logs, I don’t want it here either.

That mindset lines up with how I think about developer tooling generally. At Rise People, the SOC 2 scaffolding CLI only worked because compliance was baked into the templates. Trying to catch every issue during PR review is a losing game. Prompt hygiene is the same story. Build the guardrails into the default.

### Step 3: Cut the biggest offenders first

Prompt latency usually comes from two buckets:

- Git status in huge repos
- anything that shells out to slow CLIs or runs on slow filesystems
So we’ll focus on `git_status` and `kubernetes`.

If you want a general performance-tuning mindset, the same “budget + verify” loop is how I approach build tooling too. It’s the same playbook as [How to Reduce Rust Compile Time](/blog/reduce-rust-compile-time). Different domain. Same discipline.

## Fast Git status: tune `git_status` and stop paying for what you don’t read

The `git_status` module is one of the easiest ways to make your prompt feel bad. It’s also one of the easiest to fix, because the waste is usually self-inflicted.

You configure it in `starship.toml` via `[git_status]`. The option list is in the official docs: [Starship git_status module](https://starship.rs/config/#git_status).

My stance:

- If you only glance at **1–2 indicators**, don’t compute 10.
- If your repo has **50k untracked files** (generated assets, build output, vendor dirs), your prompt shouldn’t be the thing suffering for that.
### Practical knobs that actually move the needle

1) **Reduce what you show**

If you don’t care about stashes or conflicted counts, stop asking Starship to find them. Simplify the output. You’ll read it more, and Starship will do less work.

2) **Disable `git_status` entirely in “bad” directories**

This is the biggest win. There are repos where Git status in the prompt is just not worth it. Turn it off and rely on your editor or a manual `git status`.

3) **Use a scan timeout for repo detection**

Starship has a global `scan_timeout` that limits how long it’ll spend searching for project files while deciding what modules to show. If your prompt feels slow when you `cd` around deep trees, `scan_timeout` is a prime suspect.

I’m not giving you a single magic number because it depends on your machine and filesystem. But as a ceiling for “detection logic,” **100–300ms** is a sane range. If it can’t decide quickly, it shouldn’t decide at all.

If you want to get nerdy about this kind of constraint thinking, I apply the same approach to AI systems. Latency budgets matter more than people admit. See [AI Agent Latency Budgets](/blog/ai-agent-latency-optimization-budget).

## Kubernetes context + namespace in Starship: useful, but it needs guardrails

This is the core of the target keyword: **starship prompt kubernetes context**.

Starship’s `kubernetes` module can show context and namespace. The official config docs cover the fields, variables, and formatting options: [Starship Kubernetes module](https://starship.rs/config/#kubernetes).

### How do I show Kubernetes context in Starship prompt?

Enable the module and include it in your global `format`. Then configure `[kubernetes]` to print `$context`.

### How do I show Kubernetes namespace in my terminal prompt?

Include `$namespace` in the module `format`.

### How do I customize Starship kubernetes module?

You customize it by:

- choosing a format string that includes `$context` and/or `$namespace`
- adding aliases so you don’t print long or sensitive names
- limiting where and when the module appears
My recommendation: print **short context + namespace**, and only make it visually loud when it’s actually risky (like prod).

### Validate what Starship shows against kubectl output

Kubernetes gives you the canonical command: `kubectl config current-context`.

The Kubernetes docs page for that command shows a “modified” date of **2026-03-22**, which is exactly the kind of freshness signal I trust for CLI behavior.

Source: [kubectl config current-context](https://kubernetes.io/docs/reference/kubectl/generated/kubectl_config/kubectl_config_current-context/).

You can also list contexts:

- `kubectl config get-contexts`
If Starship is showing something you didn’t expect, don’t start by blaming Starship. Start by fixing your kubeconfig.

## Secrets hygiene: stop leaking cluster names (and check your logs)

People leak internal environment info in two places:

- the prompt itself (context names, namespaces)
- the “supporting artifacts” around the prompt (logs, screenshots, recordings)
This sounds dramatic until you realize how often terminal output ends up in Slack, PR descriptions, and public GitHub issues.

### The checklist I use

1) **Assume your context name is sensitive**

Most orgs encode a ton of info into context names. Regions, cloud accounts, environment tiers, customer names. That’s intelligence. You don’t need to make it easy.

2) **Alias contexts aggressively**

Your prompt should not print `gke_company-prod-us-east1_critical`. It should print `prod`.

Starship supports aliases for the Kubernetes module. Use them. If you can’t alias cleanly, at least adopt a naming convention that produces short, boring names.

3) **Hide context outside “k8s work” directories**

A safe default is showing Kubernetes context only when you’re in places like:

- an `infra/` repo
- a `kustomize/` folder
- a Helm chart repo
If the prompt always shows k8s context, you will eventually screen-share it at the wrong moment. It’s not a matter of discipline. It’s just probability.

If you already use per-directory environment loading, hook it up with `direnv`. I cover the mechanics in [Reproducible Terminal Dev Environment](/blog/reproducible-terminal-dev-environment).

4) **Have a recording-safe Starship config**

This is the big one. Use `STARSHIP_CONFIG` to swap configs.

- Normal: show context + namespace (aliased)
- Recording: show `k8s`, or nothing, or a generic `cluster` label
5) **Audit Starship logs for sensitive strings**

Starship logs by default to `~/.cache/starship/session_${STARSHIP_SESSION_KEY}.log`.

Search it for the stuff you never want sitting around in plain text:

- prod context names
- cloud account IDs
- internal DNS suffixes
If you work with [AI agents](/pillars/ai-agents), you already know “logs are an attack surface.” Same idea, smaller blast radius.

For a deeper CLI redaction mindset, I wrote [How to Redact Secrets in an AI Coding CLI Tool [2026]](/blog/redact-secrets-ai-cli). Different tool, same failure mode.

### A quick warning about tokens

Your prompt should never print tokens. That part is obvious.

The less obvious part is that you also shouldn’t print the breadcrumbs that help someone find tokens. Context names can encode cloud projects, cluster identifiers, and customer names. Combine that with a public repo and a few other clues, and you’ve handed an attacker a nicer starting point than you needed to.

If you want the full threat-model lens on this style of problem, see [The Complete Guide to AI Security in 2026](/blog/ai-security-complete-guide) and my write-up on [prompt injection](/blog/prompt-injection-2026-owasp-llm-vulnerability). Same rules. Don’t leak. Don’t trust inputs. Minimize exposure.

## Make the prompt calmer with transient prompts (PowerShell + Cmd)

Most Starship guides skip transient prompts, which is a shame. It’s one of the cleanest UX upgrades you can make.

The idea: after you run a command, the old prompt line gets replaced with something simpler. You keep the rich prompt for the current input line, but your scrollback stops looking like a telemetry dashboard.

Starship documents this under Advanced Configuration, split by shell:

- PowerShell: “TransientPrompt in PowerShell”
- Cmd (via Clink): “TransientPrompt and TransientRightPrompt in Cmd”
Source: Starship advanced configuration.

This matters for Kubernetes context specifically because context is exactly the kind of metadata that clutters your scrollback. You want it present while you’re typing. You don’t want it repeated 200 times in your terminal history.

If you do demos, transient prompts are also a subtle security win. Less metadata sitting around in screenshots.

## My “safe + fast” Starship setup: the defaults I’d ship to a a team

If I had to roll out Starship to an org, I’d ship something like this:

1. **Kubernetes module off by default.** Enabled only in infra repos.
1. **Kubernetes context always aliased.** No raw cluster names.
1. **Namespace shown only when it’s not `default`.**
1. **Git status simplified.** If it’s slow, it’s cut. No heroics.
1. **Two configs:** normal and recording-safe via `STARSHIP_CONFIG`.
1. **Logs treated as sensitive.** Move `STARSHIP_CACHE` to a known location and audit it.
Starship is mainstream enough now that this isn’t an edge tool anymore. The upstream repo has about **59.5k GitHub stars** and **2.6k forks**, which tells you how many people are carrying some version of this around.

Source: starship/starship on GitHub.

That popularity is great. It also means prompt conventions quietly become part of your org’s security posture whether you meant to sign up for that or not.

One more internal link if you’re doing Kubernetes-heavy work: my eBPF write-up, [7-Step Plan: eBPF Observability Without Sidecars on Kubernetes](/blog/ebpf-observability-sidecars-kubernetes), pairs nicely with this. Same theme. Less noise, more signal.

My prediction: in 2026, “prompt hygiene” becomes a normal line item in engineering enablement, the same way we standardized `pre-commit` hooks and secret scanning. If you own dev experience on your team, treat your prompt like a product. Give it a budget. Give it a threat model. Then ship it.

## FAQ

### How do I show Kubernetes context in Starship prompt?

Enable Starship’s kubernetes module and include it in your prompt format so it prints the active kubeconfig context. Then verify it matches `kubectl config current-context` so you know you’re seeing the same source of truth.

### How do I make Starship prompt faster for large git repositories?

Start by simplifying or disabling the `git_status` module for repos where it’s expensive. Then set a reasonable `scan_timeout` so Starship doesn’t spend too long detecting project context on slow filesystems or giant directory trees.

### How do I prevent leaking Kubernetes cluster/context names in demos or screen recordings?

Alias or shorten contexts so the prompt never prints raw internal names, and keep a separate “recording-safe” Starship config you can switch to using `STARSHIP_CONFIG`. Also audit Starship’s session logs in your cache directory to ensure sensitive strings aren’t being written there.