How to Show Kubernetes Context in Starship Prompt [2026]

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.

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:

→ Related: How to Redact Secrets in an AI Coding CLI Tool [2026]

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.

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.

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.)

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.

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
2. cd into the repo
3. 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.

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. 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.

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.

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.

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.

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.

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, 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 and my write-up on prompt injection. 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.
2. Kubernetes context always aliased. No raw cluster names.
3. Namespace shown only when it’s not `default`.
4. Git status simplified. If it’s slow, it’s cut. No heroics.
5. Two configs: normal and recording-safe via STARSHIP_CONFIG.
6. 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, 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.