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

Ouverte Adaptée aux débutants
#89 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

@sathpal y travaille déjà.

Depuis le 21/10/2026.

  • #90 par @sathpal — ouverte

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
69/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
go, kubernetes
Domaine
api, backend

Piste de recherche

Commence par internal/commands/builder.go, en particulier CommandBuilder.executeCommand et Execute ; suis la manière dont internal/cmd.DefaultShellExecutor.Exec renvoie la sortie combinée et dont pkg/k8s transforme les erreurs en résultats d’outil. Vérifie les tests de commandes existants et ajoute des cas couvrant une commande en échec avec une sortie. Le travail est terminé lorsque l’erreur d’outil renvoyée inclut la sortie de la commande et que les créateurs d’erreurs peuvent classifier les échecs à partir de ce message.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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.

Langage dominant
Go
Étoiles
39
Forks
31
Merge moyen
2 j 8 h
PR mergées (30 j)
2

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

  • Fournit un Dockerfile ou un fichier Docker Compose
  • Aucun modèle de pull request
  • Aucun guide de contribution

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de kagent-dev/tools

Toutes les issues de kagent-dev/tools

Issues similaires

Plus d'issues Go

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.