Skip to content

[BUG] Fix k8s_execute_command kubectl exec argv handling and honor container #59

@shladyr

Description

@shladyr

Summary

The Kubernetes k8s_execute_command tool appears broken for typical multi-token commands: the logical command line is forwarded to kubectl exec incorrectly, the optional container parameter is ignored, and failures often surface only as generic exit status 1, which hides stdout/stderr and leads agents astray.

Current behavior

  • Commands with operators like | are rejected upfront by validation (potentially dangerous characters detected) — that part may be intentional for a strict safe mode, but it blocks common diagnostics (e.g. ss -tnp | grep 5000).
  • Even simple whitespace-separated commands (e.g. echo test, ls -la, which ss, ss -tnp) fail with exit status 1 despite working when invoked manually via kubectl exec … -- ….
  • In pkg/k8s/k8s.go, the exec path passes command to kubectl in a way that effectively treats the entire string as a single argument after --, instead of splitting into argv tokens (-- echo test vs -- "echo test").
  • The container field from the tool request does not result in kubectl exec -c <container>, so targeting a specific container in a multi-container pod is unreliable.

Expected behavior

  • Commands without shell metacharacters should run with kubectl-compatible argv: after --, each token becomes a separate argument (standard kubectl exec … -- cmd arg1 arg2 …).
  • When container is set and valid, kubectl exec must receive -c <container>.
  • On failure, surface stderr/stdout (and non-zero exit) in the tool result/error path instead of opaque exit status 1 wherever possible.

Versions / scope

Still reproducible in the latest release v0.2.0 and on main (verified 2026-05-16): in pkg/k8s/k8s.go, handleExecCommand still passes the full command string as a single argv element after kubectl exec … -- and does not map the tool parameter container to kubectl exec -c …. The same behavior was already present in v0.1.3 and v0.1.4 — this code path did not change between those tags and v0.2.0 / current main.

A quick search of this repository’s issues/PRs did not find a dedicated report for k8s_execute_command / handleExecCommand (e.g. by name k8s_execute_command); if this duplicates something, please link and close.

Related but distinct: #54 / #55 (Cilium-focused kubectl exec -n). This report is about the general k8s_execute_command contract (argv splitting, -c, and error propagation).

Suggested upstream fix direction

  1. Structured API preferred long-term: command + args[], or robust parsing rules documented and tested (avoid ambiguity with quoted args if staying string-only).
  2. Honor container → always add -c when non-empty after validation.
  3. Keep strict validation by default where appropriate; if shell/pipe features are needed, expose an explicit, opt-in mode (approval / documented risk) rather than silent breakage.
  4. Tests: echo test, ls -la, ss -tnp, multi-container pod with -c, plus error cases that assert stderr is visible.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions