Skip to content

manage_skills: a call without action silently returns the index instead of failing #5604

Description

@Ninthkitten

Prerequisites

  • I searched open issues and discussions and did not find an existing report of this bug.
  • This is not a security vulnerability.
  • I am running the latest code from the dev branch.

Install Method

Docker

Operating System

macOS (Apple Silicon), Docker Desktop

Steps to Reproduce

  1. In agent mode, have a model call manage_skills without the action field — e.g. it sends only name, description and procedure, intending to create a skill.
  2. Read the tool output and then check data/skills/.

Expected Behaviour

A call that omits a required field is rejected with an error, so the caller knows nothing happened.

Actual Behaviour

In do_manage_skills, a missing or empty action falls into the list branch:

if action in ("list", "index", ""):

The caller receives the drafts index — a success-shaped response — for a call that created nothing. Nothing is written, no error is raised, and nothing anywhere indicates a failure.

Observed here: a local model made three add attempts without action and received the drafts list three times. It reported three skills created. Zero existed — nothing on disk, nothing in the index. The model's own reasoning trace shows it puzzling over why the output looked like a list, which is the only reason we caught it.

This is a bad failure mode specifically for models: a success-shaped response to a no-op teaches the caller that the operation works.

Logs / Screenshots

Tool executed: manage_skills -> exit_code=n/a
Tool executed: manage_skills -> exit_code=n/a
Tool executed: manage_skills -> exit_code=n/a

(three "add" attempts; data/skills/ unchanged)

Additional Information

Suggested fix: make action required.

if not action:
    return {"error": "action is required (list|view|add|edit|patch|publish|delete)", "exit_code": 1}

Keep list reachable explicitly; just stop treating "no action" as "list".

Related polish visible above: the list/results paths return exit_code=n/a in tool metadata where other paths return integers, so a no-op is indistinguishable from a success in the execution log too.

Are you willing to submit a fix?

Yes — the fix described above is running in production here and I can open a PR.

Metadata

Metadata

Assignees

No one assigned

    Labels

    ready for reviewDescription complete — ready for maintainer review

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions