stern has no cluster of its own - it reads your kubeconfig and tails whatever context is current, so a leftover prod context means prod logs in what you thought was a dev debug session. Check kubectl config current-context before tailing, pass stern --context [name] to pin it, or switch with kubectx first.

## The error
```text
(no error - stern silently uses the current kubectl context, so the logs are from the wrong cluster)
```

## What to do
1. Check what stern will use:
```bash
kubectl config current-context
```
   Expected: Prints the context stern follows.
2. Pin the context for this tail:
```bash
stern --context [name] [query] -n [namespace]
```
   Expected: Logs come from the intended cluster.
3. Or switch first:
```bash
kubectx [name]
stern [query] -n [namespace]
```
   Expected: Same result, and later commands follow too.

## When this applies
- logs that do not match the cluster you meant
- multi-cluster debugging sessions
- after a kubectx switch you forgot about

## When it does NOT apply
- stern failing to connect (kubeconfig problem)
- empty results on the right cluster (query/namespace problem)

## Works with
stern 1.x

### CI tails logs from the wrong cluster after a shared kubeconfig was mutated
Same shared-file cause. Give the job --context or its own KUBECONFIG.

## Why it happens
stern is a kubeconfig client like kubectl: it resolves the current context and dials that API server. There is no per-invocation cluster unless you pass --context.

## Edge cases
- --context must name a context in the kubeconfig stern reads (KUBECONFIG env or ~/.kube/config).
- Prompt tools that show the current context (kubectx in PS1) catch this before you tail.

## Resolved from
gh:esysc/stern-ui (stern context parameter) - https://github.com/esysc/stern-ui