Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

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

オープン
  • 何か問題がありますか？
#59 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 3 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
55/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
静か
技術スタック
go, kubernetes
領域
devops

調査の方向性

pkg/k8s/k8s.go の handleExecCommand から始め、コマンド、コンテナ、コマンド実行のエラーが kubectl の呼び出しとツールの結果にどのように到達するかを追跡します。空白で区切られたコマンド、コンテナの選択、stdout/stderr を公開する失敗についてテストを追加または更新します。記載された kubectl argv とエラーの動作が、指定されたバリデーションを弱めることなくカバーされていれば完了です。

索引モデルが issue の本文から書いたものです。

説明

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.
主要言語
Go
スター
35
フォーク
28
平均マージ
3日 23時間
マージ済み PR（30日）
3

環境構築

Codespaces で開く

このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。

  • Dockerfile または Docker Compose ファイルあり
  • プルリクエストのテンプレートなし
  • コントリビューションガイドなし

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

kagent-dev/tools のほかの issue

kagent-dev/tools の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。