The agent reports a namespace as completely empty — but kubectl shows twenty pods, and no error appears anywhere. Why?
The silent failure of context confusion. The server resolved a different cluster context than the one you are mentally holding — your kubeconfig current-context points at staging (or a dead kind cluster from last month), the credentials authenticate perfectly, and the cluster truthfully reports an empty namespace. Nothing errors because nothing is wrong from the API's perspective; you are simply interrogating the wrong cluster with total confidence. The engineering fix: at session start, have the agent read and report the active context and cluster server URL before any resource query — treat context verification as step zero of every incident workflow. If the empty-namespace symptom appears, wrong context is the diagnosis nine times out of ten, and the tenth is RBAC silently filtering list results.
Can it stream logs from crashed containers?
Yes — including previous-container logs via the previous flag, which is the single most valuable capability for CrashLoopBackOff diagnosis: the current container has no logs because it never lived, and the truth always sits in the previous instance.
How do I let it troubleshoot without letting it delete anything?
RBAC, not prompting. Bind the ServiceAccount to a role with only get, list, watch verbs — the API server then rejects delete and patch calls with 403s the agent cannot talk its way around. A prompt saying do not delete anything is a suggestion; a missing RBAC verb is a wall.
Does it work with managed clusters (EKS, GKE, AKS)?
Yes, with one friction point: managed clusters use short-lived exec-plugin credentials (aws eks get-token, gke-gcloud-auth-plugin). The binary for that plugin must exist in the MCP server process environment, or authentication fails when the cached token expires mid-session.