Summary

In Telegram, /background <prompt> does not consistently behave like a side-task command when the main session is already busy. Instead of starting a separate background task, it can interrupt the active conversation and feed the literal slash command back through the interrupt path.

Reproduction

1. Start a long-running task in a Telegram chat with Hermes.
2. While that task is still running, send a message like:

   /background check out the new allium mcp https://docs.allium.so/ai/mcp/overview https://agents.allium.so set it up with our api key instead of doing the existing way we're using allium
   

3. Observe that Hermes may interrupt the active run instead of cleanly launching the background task.

Expected behavior

/background should behave like a side-channel command even while the main run is active:

• it should start a separate background task
• it should not interrupt the active conversation
• it should not be passed through as ordinary interrupt text

Actual behavior

In Telegram gateway sessions, /background can be treated like a normal incoming message during an active run and trigger the active-session interrupt flow. From the user's perspective, this looks like /background failed to queue a side task and instead hijacked the main conversation.

Likely cause

This looks like a gateway busy-session dispatch gap rather than a background-task runner bug. There are two places to check:

1. gateway/platforms/base.py active-session guard
   Certain slash commands bypass the active-session guard and are dispatched directly, but /background may not be consistently included there.

2. gateway/run.py running-agent fast path
   When a session already has a running agent, /background appears to fall through to the default interrupt behavior instead of being routed to _handle_background_command(...).

Scope

Observed in Telegram. This may also affect other gateway platforms that share the same busy-session command dispatch path.

Notes

Restarting the gateway can clear the current in-memory active session state, but that does not appear to fix the underlying bug. The issue reproduces again on later active runs.