[BUG] Failed commands return only "exit status 1"; the command's error never reaches the agent

Aperta Adatta ai principianti
  • Qualcosa non va?
#89 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

@sathpal ci sta già lavorando.

Dal 21/10/2026.

  • #90 di @sathpal — aperta

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
69/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
go, kubernetes
Ambito
api, backend

Direzione di ricerca

Inizia da internal/commands/builder.go, in particolare da CommandBuilder.executeCommand e Execute; segui il modo in cui internal/cmd.DefaultShellExecutor.Exec restituisce l’output combinato e pkg/k8s converte gli errori in risultati dello strumento. Controlla i test dei comandi esistenti e aggiungi casi per un comando non riuscito con output. Il lavoro è completato quando l’errore dello strumento restituito include l’output del comando e i creatori di errori possono classificare gli errori a partire da quel messaggio.

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

Descrizione

Bug · Severity: Medium · every tool that runs a CLI · no workaround on the agent side
Affects: kagent-tools v0.1.x to v0.3.0 (bundled with kagent v0.10.3) and main · Component: internal/commands (CommandBuilder.Execute)

What breaks

When a CLI command fails, the tool result tells the agent only the exit status. The command's own message, the part that says why it failed, is written to the tool server's log and dropped.

Asking kagent's k8s-agent to "Show me the YAML of the deployment does-not-exist in the default namespace" gives the agent this tool result:

[Kubernetes] get deployment does-not-exist -o yaml -n default failed: exit status 1

The tool server logs what kubectl actually said:

level=ERROR msg="command execution failed" command=kubectl args="[get deployment does-not-exist -o yaml -n default]" error="exit status 1" output="Error from server (NotFound): deployments.apps \"does-not-exist\" not found\n"

For NotFound the agent can guess. For most failures it can't. In my case an admission webhook refused a k8s_patch_resource call and said exactly what to do next:

Error from server (Forbidden): admission webhook "agents.kubeamber.dev" denied the request: kubeamber: HOLD (risk 40/100, replicas 3 → 6): risk 40/100 is at or above the hold threshold (30). Factors: +10 modifies a resource, +5 changes a workload, +25 namespace "prod" is protected. Held for human approval as change request cr-671cf823-tqrcc (expires in 1h0m0s). Ask an operator to run `kubeamber approve cr-671cf823-tqrcc`, then retry this exact change.

The agent received exit status 1. It then tried the same change three different ways (a merge patch, an annotation, and kubectl apply of an edited manifest) and asked the user whether they had RBAC permissions or "an admission controller, policy, or automation tool … restricting changes". The same happens with RBAC denials, conflicts, validation errors, and failed helm, istioctl and cilium commands.

There is a second effect. NewKubernetesError, NewHelmError and the other error creators choose suggestions and an error code by searching the cause for words such as forbidden, not found and already exists. The cause is always the exit error, so those branches never match: every kubectl failure gets K8S_GENERIC_ERROR. The Helm tools show these suggestions to the agent, so the agent gets the generic fallback for those too.

Reproduce

kagent v0.10.3 on kind with the default install. Ask k8s-agent for any resource that doesn't exist, as above, and expand the tool call's result in the UI. Then compare it with the tool server's log:

kubectl -n kagent logs deploy/kagent-tools | grep "command execution failed"

Expected vs actual

  • Expected: the tool result includes the command's output, for example ... failed: exit status 1: Error from server (NotFound): deployments.apps "does-not-exist" not found.
  • Actual: it ends at failed: exit status 1.

Ask

Keep the command's output in the error that CommandBuilder.Execute returns. I have a small PR ready that does this and adds a test.

Root cause

internal/cmd.DefaultShellExecutor.Exec runs cmd.CombinedOutput() and returns both the output and the error. CommandBuilder.executeCommand (internal/commands/builder.go; this handling dates from #7) wraps only the error:

output, err := executor.Exec(ctx, command, args...)
if err != nil {
    var toolError *errors.ToolError
    switch command {
    case "kubectl":
        toolError = errors.NewKubernetesError(strings.Join(args, " "), err)
    ...
    return string(output), toolError
}

and Execute then discards the returned output (return "", err). runKubectlCommand in pkg/k8s turns the error into the tool result with mcp.NewToolResultError(err.Error()), so only exit status 1 survives.

Lingua principale
Go
Stelle
39
Fork
31
Merge medio
2g 8h
PR unite (30g)
2

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.