Bug report draft: busy_input_mode=queue still interrupts process.wait() on new messages

Summary

When display.busy_input_mode is set to queue, sending a new message during an active gateway conversation can still interrupt a running process.wait() call. This appears to violate the expected queue semantics: follow-up messages should wait until the current task completes rather than interrupting tool execution.

Expected behavior

With:

display:
  busy_input_mode: queue

A new user message in the same gateway session should be queued and processed after the current task finishes. In particular, long-running waits on background processes should not be interrupted by the follow-up message.

Actual behavior

A follow-up message causes process.wait() to return early with:

{
  "status": "interrupted",
  "note": "User sent a new message -- wait interrupted"
}

The assistant then receives the system notice that the previous turn was interrupted.

Evidence collected

Local config was confirmed to contain:

display:
  busy_input_mode: queue

Relevant code paths observed in v2026.4.16:

• gateway/run.py
  • _load_busy_input_mode() returns "queue" when config/env says queue.
• tools/process_registry.py
  • wait() explicitly checks tools.interrupt.is_interrupted().
  • On interrupt, it returns early with note:
    • User sent a new message -- wait interrupted
• tools/interrupt.py
  • interrupt signaling is thread-scoped and triggered by new-message interrupt handling.

This suggests queue semantics at the gateway/agent level are not fully aligned with tool-level interrupt handling for process.wait().

Why this looks like a bug

From the user perspective, busy_input_mode=queue promises “new messages wait instead of interrupting the current task.” But in practice, tool waiting can still be interrupted by a new message, so the current task is not fully protected from interruption.

Possible root cause

busy_input_mode=queue appears to control gateway/session follow-up handling, but process.wait() still honors a generic interrupt signal raised when a new message arrives. That creates an implementation mismatch between queued follow-up behavior and tool-level interruption.

Suggested fix directions

One of these likely needs to happen:

1. In queue mode, do not set the interrupt signal for the active agent/tool thread when the follow-up should be queued.
2. Or, make process.wait() ignore new-message interrupts when the current session is in queue mode.
3. Or, make the queue/interrupt contract explicit in docs if current behavior is intentional (though it seems surprising and inconsistent).

Repro outline

1. Set display.busy_input_mode: queue.
2. Start a task that uses a background process and then waits with process.wait().
3. While process.wait() is blocking, send another message in the same Telegram/gateway session.
4. Observe that process.wait() exits early as interrupted instead of allowing the current task to finish and queuing the new message.

Environment

• Hermes Agent version: v2026.4.16
• Platform: Telegram gateway
• Config: display.busy_input_mode: queue