Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#59 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

@Devamparikh ci sta già lavorando.

Dal 9/7/2026.

  • #67 di @Devamparikh — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
55/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
go, kubernetes
Ambito
devops

Direzione di ricerca

Inizia in pkg/k8s/k8s.go, in handleExecCommand, e segui come gli errori del comando, del container e dell'esecuzione del comando arrivano all'invocazione di kubectl e al risultato dello strumento. Aggiungi o aggiorna i test per i comandi separati da spazi bianchi, la selezione del container e i fallimenti che espongono stdout/stderr; il lavoro è completato quando i kubectl argv elencati e il comportamento degli errori sono coperti senza indebolire la validazione indicata.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.
Lingua principale
Go
Stelle
36
Fork
29
Merge medio
3g 23h
PR unite (30g)
3

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di kagent-dev/tools

Tutte le issue di kagent-dev/tools

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.