Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#59 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 3 days

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
55/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Quiet
Tech stack
go, kubernetes
Domain
devops

Research direction

Start in pkg/k8s/k8s.go at handleExecCommand and trace how the command, container, and command errors reach the kubectl invocation and tool result. Add or update tests for whitespace-separated commands, container selection, and failures that expose stdout/stderr; done means the listed kubectl argv and error behavior are covered without weakening the stated validation.

Written by the indexing model from the issue text.

Description

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.
Dominant language
Go
Stars
35
Forks
30
Avg merge
3d 23h
Merged PRs (30d)
3

Getting set up

We have not checked this project's setup files yet. Start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from kagent-dev/tools

All issues in kagent-dev/tools

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.