[BUG] Queued messages interfere with tool responses that require user interaction

[martin-rueegg]

Problem (one or two sentences)

When queueing and input, and the agent then uses either attempt_completion , the queued message is automatically sent to the agent AND the default button pressed. Which means, the message is lost in the child task (where it is saved but not acted upon) and the parent task only receives the content of the attempt completion command.

I think it also happens with execute_command tool.

Context (who is affected and when)

Everyone using subtasks and queues a message during a long running agent turn that ends with an attempt_completion question.

Reproduction steps

1. let the task create a child task that does some work long enough for you to queue a message and then finishes with and attempt_complete call
2. while the child task is busy, write some other input and queue it.
3. wait and watch

Expected result

The child task would process the input instead of confirming the completion and passing control back to the parent.

Actual result

the message is lost in the child task (where it is saved but not acted upon) and the parent task only receives the content of the attempt completion command. control is now in the parent.

Variations tried (optional)

execute_command does also "hit" the default button (Deny) but since the control stays in the child task, the affect is only that the command-call needs to be re-issued (but the agent does not know, why the task was denied)

App Version

v3.78.0, v3.76.0

API Provider (optional)

No response

Model Used (optional)

No response

Zoo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[martin-rueegg]

I would suggest that there are a list of tool names (or responses) that do NOT trigger the default button and the delivery of the queued message.

proposed list:

• attempt_completion
• ask_followup_question
• execute_command

[zoomote]

Tracking this under #355 as a cross-cutting queue/approval invariant, with follow-through in #372, #377, and #378.

Implementation is starting TDD-first: encode the reproduced Task.ask() behavior as a failing regression test, then change queued input to resolve as messageResponse rather than an implicit button click. We will keep command_output as the non-draining flow-control exception.