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
- Structured API preferred long-term:
command + args[], or robust parsing rules documented and tested (avoid ambiguity with quoted args if staying string-only).
- Honor
container → always add -c when non-empty after validation.
- 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.
- Tests:
echo test, ls -la, ss -tnp, multi-container pod with -c, plus error cases that assert stderr is visible.
Summary
The Kubernetes
k8s_execute_commandtool appears broken for typical multi-token commands: the logical command line is forwarded tokubectl execincorrectly, the optionalcontainerparameter is ignored, and failures often surface only as genericexit status 1, which hidesstdout/stderrand leads agents astray.Current behavior
|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).echo test,ls -la,which ss,ss -tnp) fail withexit status 1despite working when invoked manually viakubectl exec … -- ….pkg/k8s/k8s.go, the exec path passescommandtokubectlin a way that effectively treats the entire string as a single argument after--, instead of splitting into argv tokens (-- echo testvs-- "echo test").containerfield from the tool request does not result inkubectl exec -c <container>, so targeting a specific container in a multi-container pod is unreliable.Expected behavior
kubectl-compatible argv: after--, each token becomes a separate argument (standardkubectl exec … -- cmd arg1 arg2 …).containeris set and valid,kubectl execmust receive-c <container>.stderr/stdout(and non-zero exit) in the tool result/error path instead of opaqueexit status 1wherever possible.Versions / scope
Still reproducible in the latest release
v0.2.0and onmain(verified 2026-05-16): inpkg/k8s/k8s.go,handleExecCommandstill passes the fullcommandstring as a single argv element afterkubectl exec … --and does not map the tool parametercontainertokubectl exec -c …. The same behavior was already present inv0.1.3andv0.1.4— this code path did not change between those tags andv0.2.0/ currentmain.A quick search of this repository’s issues/PRs did not find a dedicated report for
k8s_execute_command/handleExecCommand(e.g. by namek8s_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 generalk8s_execute_commandcontract (argv splitting,-c, and error propagation).Suggested upstream fix direction
command+args[], or robust parsing rules documented and tested (avoid ambiguity with quoted args if staying string-only).container→ always add-cwhen non-empty after validation.echo test,ls -la,ss -tnp, multi-container pod with-c, plus error cases that assert stderr is visible.