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

Abierto Apto para principiantes
  • ¿Algo no está bien?
#89 0 comentarios 0 reacciones 0 asignados Ver en GitHub

@sathpal ya está trabajando en esto.

Desde el 21/10/2026.

  • #90 de @sathpal — abierto

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
69/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
go, kubernetes
Área
api, backend

Línea de trabajo

Empieza por internal/commands/builder.go, especialmente por CommandBuilder.executeCommand y Execute; sigue cómo internal/cmd.DefaultShellExecutor.Exec devuelve la salida combinada y cómo pkg/k8s convierte los errores en resultados de herramientas. Revisa las pruebas existentes de comandos y añade cobertura para un comando fallido con salida. El trabajo estará terminado cuando el error de herramienta devuelto incluya la salida del comando y los creadores de errores puedan clasificar los fallos a partir de ese mensaje.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Go
Estrellas
39
Forks
31
Merge medio
2 d 8 h
PR fusionados (30 d)
2

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de kagent-dev/tools

Todos los issues de kagent-dev/tools

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.