[Bug]: MCP t3_thread_send with mode auto still fails on a run that is stopping (follow-up to #32891) #34158

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

This is the mode: "auto" half of #32891, which closed when #32899 merged. #32899 fixed the explicit restart case. The auto case is still on main at 0f13d2c.

1. Thread A has a running turn. A thread.stop reaches it, and the provider has not stopped yet. On a long thread that window is wide (Sending, editing or steering queued messages takes 7-15 seconds in a long thread #29468).
2. Another thread calls t3_thread_send to thread A with mode: "auto".
3. The send fails with Target run run:thread:<thread>:ordinal:N is stopping and cannot be steered.

Why, with line numbers read on main 0f13d2c:

• apps/server/src/orchestration-v2/ThreadManagementService.ts: sendToThread turns auto with a steerable run into dispatchMode = { type: "steer_active", targetRunId } (L848-849) and dispatches message.dispatch with no deliveryIntent (L856-869).
• apps/server/src/orchestration-v2/Orchestrator.ts: the guard that changes a steer to queue_after_active once Stop has reached the run only applies when command.deliveryIntent === "auto" (L6097-6103), so an MCP send skips it. The new restart_active branch added by fix(server): a restart that misses its turn starts as a new turn #32899 (L6104-6111) does not apply to steer_active. The send goes on to dispatchSteerIntoRun and fails at L5189-5195.

The comment above the guard says an explicit steer still fails, which fits mode: "steer". A caller who sent auto did not ask for an explicit steer.

Expected behavior

An MCP send with mode: "auto" to a run that Stop has reached queues behind it, the way the guard at L6093-6103 already handles a send that carries deliveryIntent: "auto".

Actual behavior

The send fails. A retry with the same clientRequestId returns the stored rejection (Command ... was previously rejected: Failed to dispatch orchestration command message.dispatch), so the caller has to know to pick a new id. The same text sent with a new id came back queued.

Impact

Minor bug or occasional failure

Version or commit

Seen on 0.1.9-nightly.20261110.4452 (8226715). The same code is on main at 0f13d2c, after #32899.

Environment

macOS 15.8.1, arm64, T3 Code (Nightly) desktop with its bundled server. Claude provider.

Logs or stack traces

# Nov 10, 2026, UTC, one thread
11:30:03Z  thread.stop starts on the thread (it took 74 s)
11:31:18Z  message.dispatch from t3_thread_send (mode auto) starts
11:31:19Z  run 6775 ends, status interrupted
           the dispatch fails after 47.4 s:
           Unable to send to thread <thread>: Target run run:thread:<thread>:ordinal:6775 is stopping and cannot be steered.

Workaround

Send again with a new clientRequestId.

Related: #32891 (I described this case in a comment there a few minutes before it closed), #32899, #32902. Passing the MCP mode as a deliveryIntent, as #32891 suggested, would cover it.

Investigated with Claude Code.