(bug) Sending a message while an agent turn runs kills the turn and locks the session for 30 minutes

[mmabrouk]

When I send a message to an agent session while its current turn is still running, I expect the platform to queue the message, or to refuse it with a clear signal. Instead both turns die and the session refuses every message for 30 minutes.

What happens:

1. The new message aborts at once. The chat shows "Agent run failed: This operation was aborted".
2. The running turn stops producing output at the same moment and never completes.
3. Every later message aborts the same way, until the 30-minute idle limit reaps the dead turn. Only then does the session accept messages again.

Steps to reproduce

1. Start an agent session and send a prompt that produces a long turn (several minutes of tool calls).
2. While the turn streams, send a second message in the same session.
3. Watch the second message fail at once, the first turn go silent, and the session stay stuck. Send more messages: each one fails with the same abort.

Reproduced on the local OSS dev stack on 2026-08-31, session 4ad72652-d294-4e9c-b224-c90e4b11e43c. The first turn streamed normally from 19:22 to 19:30:16. The second message arrived at 19:30:18.

Runner log

19:30:16 [sessions/persist] ingest OK session=4ad72652... idx=67 type=tool_result   <- healthy turn b3e552b3 still streaming
19:30:18 [sessions] stream sessionOwned=true sessionId=4ad72652... turnId=7a0e728a... cred=present
19:30:18 [sessions/alive] interrupted session=4ad72652... turn=7a0e728a... -> aborting   <- new turn refused by the turn locks
19:30:19 [keepalive] evict (supersede-busy) key=...:4ad72652...; cold                    <- but the busy sandbox is torn down anyway
19:30:19 [keepalive] evict key=...:4ad72652... reason=supersede-busy

After the eviction, the first turn (b3e552b3) produced nothing more, but kept heartbeating running=true every 30 seconds until:

20:00:19 [sessions/persist] ingest OK session=4ad72652... idx=69 type=error   ("idle timeout after 1800000ms with no progress")

SDK log for the aborted new turn

agenta.sdk.agents.errors.AgentRunFailed: Agent run failed: This operation was aborted

The hang half of this (a turn that never fails when its sandbox dies under it) is #6418. The codex no-output case is #6420.

[linear-code]

AGE-4223

[dosubot]

This looks like the same underlying gap flagged in #5539: the runner has no start-time gate on concurrent turns for the same session. Exclusivity is only enforced after the fact via the 30-second heartbeat, and the "loser" isn't cleanly rejected — it's torn down mid-flight instead [1].

Your log confirms the specific failure mode: the second message's turn (7a0e728a) gets interrupted -> aborting from the turn lock, but the keep-alive pool still evicts the busy sandbox with reason=supersede-busy right after [2]. So the running turn (b3e552b3) loses its sandbox even though it "won" the lock contention — it's left silently orphaned: no more output, but the alive watchdog keeps heartbeating running=true until the 30-minute idle limit (AGENTA_RUNNER_RUN_IDLE_TIMEOUT_MS) finally reaps it and frees the session [3].

Two related reports converge on the same root cause:

• #6418 covers this exact half — a turn that loses its sandbox (e.g. to supersede-busy) but doesn't fail fast; runTurn never resolves and the turn keeps holding the session's locks until the idle timeout, which is what forces the 30-minute lockout you're seeing.
• #6020 documents a closely related steer-message scenario where the interrupt lands on the new turn instead of superseding the old one, also ending in evict (supersede-busy) and a dead session — same symptom, slightly different trigger (stop-and-retype vs. plain concurrent send).

The "queue or refuse cleanly" behavior you're expecting doesn't exist yet: there's no start-time gate to refuse the second message before work begins, and the eviction/interrupt paths kill the wrong side (or both sides) instead of cleanly superseding [1]. The relevant code spans alive.ts (heartbeat + interrupted), session-pool.ts (keepalive eviction), and the abort path in run-turn.ts. Given #6417, #6418, and #6020 are converging on the same runner subsystem, it may be worth tracking them together as one fix rather than three separate patches.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.