tool confirmation failures are mysterious

[nicks]

Describe the bug

If the request to approve a tool call fails, the output is extremely mysterious:

• the cagent api returns 200
• the agent has no idea what happened

Version affected

v1.19.1

How To Reproduce

I pushed up a branch with a test harness to make it easier to see the behavior

e11eee4

1. Run cagent api with an agent config that has a tool
2. Call the /resume api with {"confirmation": "garbage"}

Output:

Session created: ea7e7209-1c5e-46a8-8d36-2dd5550c1052

Running agent...

[Stream Started] Session: ea7e7209-1c5e-46a8-8d36-2dd5550c1052, Agent: root
[Tool Confirmation Required] start-task
[Resuming session with: garbage]
The tool execution failed. Unfortunately, the system returned a generic failure message without providing specific error details. This appears to be a bug in the `start-task` tool - it should return more informative error messages to help diagnose what went wrong, such as:

- Whether the task name "demo-task" is invalid or already exists
- Whether there are permission issues
- Whether the backend service is unavailable
- What the specific validation or system error is

**Bug Report:** The `start-task` tool needs to provide more descriptive error messages when execution fails, rather than just reporting "(tool execution failed)" without context.

Expectation

The agent should report some sort of meaningful error -- e.g., that the tool call was rejected.

[Pnkcaht]

@nicks I'll take a look here and create a pull request with more descriptive information

[Pnkcaht]

Summary

Hi @nicks, I opened a PR that addresses the confusing behavior you reported when resuming a session with an invalid confirmation value.

Before, sending an invalid value (e.g. "garbage") to /resume returned 200 OK and later failed with a generic (tool execution failed) message, without indicating that the tool call had been explicitly rejected.

With this change, the confirmation is validated upfront and invalid values are rejected with a clear, explicit error. The runtime and agent never attempt tool execution in this case, so the failure reason is immediately clear to the user.

PR: #1414

Screenshot