Bug Description

When Hermes is running on Discord with display.busy_input_mode: queue, a self-restart triggered from Discord can still have its in-flight work interrupted by a follow-up Discord message during the restart window.

In my local repro, the gateway restart itself succeeded, but the in-flight hermes gateway restart command surfaced as interrupted (exit 130 in the agent tool runner) after a follow-up Discord message arrived.

This makes queue mode misleading for gateway/Discord restart behavior: the system appears to behave as if new input can still stomp on in-flight work during restart, even though all live configs are set to queue.

This seems distinct from #6315:

• fix(discord): avoid false ❌ on self-restart cancellation #6315 / PR fix(gateway): avoid false failure reactions on restart cancellation #6942 are about false terminal failure reactions (❌) on expected restart cancellation
• this issue is about queue mode not being honored, or not applying, in the Discord gateway restart path

Steps to Reproduce

1. Set display.busy_input_mode: queue
2. Run Hermes gateway on Discord
3. Trigger a self-restart from Discord
4. While the restart is in flight, send another Discord message before the restart sequence fully settles

Expected Behavior

With queue mode enabled, the follow-up Discord message should be queued for later processing instead of interrupting the in-flight restart-related work.

At minimum, Hermes should not behave as though the new Discord message interrupted the active command path.

Actual Behavior

The restart completed successfully, but the in-flight command path was still interrupted when a new Discord message arrived during the restart window.

Environment

• Hermes checkout: ff6a86cb529a372198b4b80d5e022e32a4a3f2cc
• Branch: main
• OS: macOS
• Gateway mode: launchd service
• Profiles checked:
  • ~/.hermes/config.yaml
  • ~/.hermes/profiles/opus/config.yaml
  • ~/.hermes/profiles/research/config.yaml
• All three had display.busy_input_mode: queue

Relevant Config Evidence

# ~/.hermes/config.yaml
 display:
   resume_display: full
   busy_input_mode: queue

# ~/.hermes/profiles/opus/config.yaml
 display:
   resume_display: full
   busy_input_mode: queue

# ~/.hermes/profiles/research/config.yaml
 display:
   resume_display: full
   busy_input_mode: queue

Relevant Local Logs

Gateway shutdown/startup sequence:

2026-04-10 09:43:10,343 INFO gateway.run: Gateway stopped
2026-04-10 09:43:13,286 INFO gateway.run: Starting Hermes Gateway...
2026-04-10 09:43:13,411 INFO gateway.run: Connecting to discord...
2026-04-10 09:43:16,613 INFO discord.gateway: Shard ID None has connected to Gateway (Session ID: 3d56eb60a20c838b4f8dc895dc9ff873).
2026-04-10 09:43:18,618 INFO gateway.platforms.discord: [Discord] Connected as gpt#7911
2026-04-10 09:43:19,171 INFO gateway.platforms.discord: [Discord] Synced 100 slash command(s)
2026-04-10 09:43:19,172 INFO gateway.run: ✓ discord connected
2026-04-10 09:43:20,561 INFO gateway.run: ✓ telegram connected
2026-04-10 09:43:20,563 INFO gateway.run: Gateway running with 2 platform(s)
2026-04-10 09:43:29,600 INFO gateway.run: inbound message: platform=discord user=boba shop cashier chat=1491242728900792422 msg='what? give me a log of what happened'

Process evidence that the restart actually succeeded:

old PID before restart: 55669
new PID after restart: 61333
PID STARTED                      COMMAND
61333 Fri Apr 10 09:43:12 2026   /Users/kennyxie/.hermes/hermes-agent/venv/bin/python -m hermes_cli.main gateway run --replace

Code Evidence / Likely Root Cause

A content search on the local checkout found busy_input_mode in CLI code, but not under gateway/.

Hits exist in:

• hermes_cli/config.py
• cli.py
• CLI tests

No hits under:

• gateway/**/*.py

That suggests display.busy_input_mode may currently be a CLI-only behavior knob and may not be wired into gateway/Discord session handling at all.

Why This Matters

If queue mode is documented or expected to control how busy sessions handle new input, the gateway should either:

• honor it in Discord/Telegram/etc., or
• clearly document that it is CLI-only

Right now it smells like a config knob that looks global but is not actually respected by the gateway path.