Bash tool requires description, and a model that omits it loops on the rejected call

[eXsoR65]

Bash tool rejects calls that omit description, and the agent retries the same call

Environment

• DeepSeek Harness 0.2.1-rc.5 (web profile), Node 24.
• Model served over an OpenAI-compatible /v1 endpoint (local 24B model, openai-completions protocol).
• Default standard preset, 31 tools.

Symptom

Every bash call from this model is rejected:

Error: invalid arguments: missing required property "description"

The model then sends the same call again, unchanged. In one turn that produced 23 rejected bash calls across 31 steps, with the same command repeated 9 times, and the turn never answered. Nothing surfaces in the UI beyond the normal busy state; the session log is the only place the error appears.

This is on a model that behaves correctly against the same endpoint with a single tool, so it is not a broken endpoint.

What the model actually emits

Measured against the same server, same tool schema (required: ["description", "command"]):

request	tool-call arguments
one tool, no system message	{"description":"List files in /home/user/notes","command":"ls -la /home/user/notes"}
one tool + any system message	{"command":"ls -la /home/user/notes"}
31 tools + system message	{"command":"ls -la /home/user/notes"}
parameter renamed description → label	{"command": …} (so it is not the name)
strict: true, additionalProperties: false	{"command": …}
system prompt adds "always include every required argument"	works with one tool, fails with 31

So the trigger is the presence of a system message, and the model treats a UI-label-shaped field as optional metadata. A two-argument tool whose fields are both data (file_path + content) is filled correctly in every case, which is why this shows up on bash specifically.

Why it compounds

The failure is model-visible as a tool result, but the model does not adapt: it repeats the identical call until the step budget is spent. There is no repeated-identical-call guard, so one schema mismatch turns into a stalled turn rather than one failed step.

Suggested changes

1. Treat description as optional. It is a UI label; command is the only thing execution needs. Deriving a label from the command's first line when it is absent keeps the terminal card useful. This removes the failure mode for every model that treats the field as metadata, not just this one.
2. If it stays required, contain the loop. A repeated-identical-call breaker (same tool + same arguments twice or three times consecutively) would turn a 30-step stall into one clear error. That is worth having independently of this issue.

Workaround

A tools/pre-execute handler can fill a missing description from command before the tool body validates its arguments:

export const name = 'bash-argument-fallback'
export const inject = ['tools']

export function apply(ctx) {
  ctx.on('tools/pre-execute', async (exec, next) => {
    if (exec?.name === 'bash') {
      const args = exec.arguments
      if (args && typeof args === 'object' && (typeof args.description !== 'string' || args.description.trim() === '')) {
        const line = String(args.command ?? '').trim().split('\n').find(part => part.trim().length > 0) ?? 'Run command'
        exec.arguments = { ...args, description: line.slice(0, 80) }
      }
    }
    return next()
  })
}

That restores execution, though the recorded call still lacks the field; relaxing the schema as in suggestion 1 is what makes the presentation path correct too.

Happy to provide the fuller version (with tests) if it is useful.

[PedroCostinha]

Hi! One additional safeguard worth considering is repeated-call detection at the tool dispatch boundary.

Making description optional or supplying a safe default could address this particular schema mismatch, but it would not prevent similar loops caused by other invalid arguments.

I would suggest tracking consecutive calls with the same tool name and normalized arguments. After a small configurable threshold, the runtime could return a clear validation failure instead of repeatedly executing the same rejected request.

A useful regression test would verify that a missing description cannot cause an unbounded loop, both with a minimal tool set and with the larger tool configuration.

This would make the integration more resilient even when a model produces unexpected tool arguments.