[BUG] Queued prompts trigger auto-approval of agent-requested commands

[TrawenCZ]

Problem (one or two sentences)

When agent is in mode where it can execute commands, is working on something, and you meanwhile place a prompt into queue, and (another meanwhile) agent decides to call tool for executing command, it results in auto-approving the command regardless of what it is (even if not in your auto-approved commands).

Context (who is affected and when)

Happens to whoever uses agent with command execution capability and is adding prompts to queue.

Reproduction steps

1. Open ZooCode in VSCode
2. Select mode with "Run Commands" tools available (for example the default "Code" mode)
3. Tell agent to run some command, best is one that you don't have in auto-approved commands to see it approves anything, but also something non-destructive (e.g., "ps && echo "hello")
4. Right after you send the prompt in step 3, write and send for example "don't do that", or any other message (agent must not finish before you send this, your message must be in queue)
5. Watch the command being executed without your approval

Expected result

To not auto-approve command by placing prompts into queue.

Actual result

Prompts in queue result in auto-approved commands.

Variations tried (optional)

No response

App Version

v3.82.0

API Provider (optional)

None

Model Used (optional)

No response

Zoo Code Task Links (optional)

No response

Relevant logs or errors (optional)

[jg-noncelogic]

This looks like an input-routing boundary rather than only an auto-approve matcher bug: a queued user message must never satisfy an approval unless it carries the identity of the exact request the reviewer saw.

A small regression slice I would add:

1. Start command request A and leave its approval pending.
2. Queue an ordinary user message B (including text such as “don’t do that”).
3. Assert B remains ordinary conversation input and A remains pending.
4. Send a decision bound to (request_id, display_epoch, authority_digest) for A.
5. Assert only that exact tuple can approve A; a stale epoch, changed digest, bare yes/no, or generic queued message is rejected fail-closed.
6. Race B and the bound decision in both orders and assert exactly one dispatch only after the valid decision.

The concrete transition is PENDING -> VISIBLE_UNARMED -> ARMED -> DECIDED; generic queue input has no transition into DECIDED. Approval routing should run against the armed request before generic busy/queue handling, while unrelated input stays unrelated.

I wrote an AI-assisted, implementation-neutral queue/supersession contract with this case plus stable prompt identity, cancellation, fairness, and restart checks: https://gist.github.com/jg-noncelogic/97b50f7321467e7b39508fdbf98db3d9

The directly relevant checks are 2-7, 13, 26-27, and 30.