What causes "current-cluster - invalid context specified: %q" in derailed/k9s?

Compare the flag value against kubectl config get-contexts output and fix the spelling

current-cluster - invalid context specified: %q

Error message

current-cluster - invalid context specified: %q

What it means

Returned by Config.CurrentClusterName (internal/client/config.go:148) in the branch where a --context override flag is set (isSet(c.flags.Context)). Even though the kubeconfig's own current-context resolved fine, the explicitly requested context is not present in the contexts map, so its cluster cannot be determined. The 'current-cluster - ' prefix distinguishes this from the current-context variant at line 143.

Source

Thrown at internal/client/config.go:148

// CurrentClusterName returns the currently active cluster name.
func (c *Config) CurrentClusterName() (string, error) {
	if isSet(c.flags.ClusterName) {
		return *c.flags.ClusterName, nil
	}
	cfg, err := c.RawConfig()
	if err != nil {
		return "", err
	}

	ct, ok := cfg.Contexts[cfg.CurrentContext]
	if !ok {
		return "", fmt.Errorf("invalid current context specified: %q", cfg.CurrentContext)
	}
	if isSet(c.flags.Context) {
		ct, ok = cfg.Contexts[*c.flags.Context]
		if !ok {
			return "", fmt.Errorf("current-cluster - invalid context specified: %q", *c.flags.Context)
		}
	}

	return ct.Cluster, nil
}

// CurrentContextName returns the currently active config context.
func (c *Config) CurrentContextName() (string, error) {
	if isSet(c.flags.Context) {
		return *c.flags.Context, nil
	}
	cfg, err := c.RawConfig()
	if err != nil {
		return "", fmt.Errorf("fail to load rawConfig: %w", err)
	}

	return cfg.CurrentContext, nil
}

View on GitHub (pinned to 2d3ccc6ba2)

Solutions

Compare the flag value against kubectl config get-contexts output and fix the spelling
Drop the --context flag entirely to fall back to the kubeconfig's current-context
If the context is expected, create or restore it in the kubeconfig that is actually being loaded (check KUBECONFIG)

Example fix

# before
k9s --context prod-eu-wrong

# after
kubectl config get-contexts   # find exact name e.g. 'prod-eu1'
k9s --context prod-eu1

Defensive patterns

Strategy: validation

Validate before calling

func validateContextFlag(cfg *client.Config, flagCtx string) error {
	ctxs, err := cfg.Contexts()
	if err != nil {
		return err
	}
	if _, ok := ctxs[flagCtx]; !ok {
		return fmt.Errorf("--context %q unknown; available: %v", flagCtx, maps.Keys(ctxs))
	}
	return nil
}

Prevention

Validate --context values against kubectl config get-contexts in wrapper scripts before exec'ing k9s
Avoid pinning context names in aliases; resolve them dynamically at launch
After renaming contexts (kubectx), grep your shell config and scripts for the old name

When it happens

Trigger: Launching k9s (or constructing Config) with --context <name> where <name> is not a key in the merged kubeconfig contexts: a typo, a stale flag/alias referencing a renamed context, or a wrapper script hardcoding a context that no longer exists.

Common situations: Shell aliases or launcher scripts pinned to an old context name; kubectx renames while muscle memory types the old name; CI job templates with hardcoded --context values after cluster migration.

Related errors

AI-assisted analysis of derailed/k9s@2d3ccc6ba2 (2026-08-15). Data as JSON: /api/errors/566b3d8fd45b657f. Report an issue: GitHub.