Repository navigation
Explicit steer is refused with "No running provider turn found" during run startup/completion gaps #23271
Description
Summary
When a user sends a follow-up with the default Steer follow-up behavior while a run is active but has no running provider turn, the message is refused with No running provider turn found for active run <runId>. This happens when the run is starting, before the provider's first event, or in the gap as a turn finishes. The message isn't delivered.
#15600 / #15691 fixed this for deliveryIntent: "auto". The client sends an explicit deliveryIntent: "steer" whenever it sees a run as running and followUpBehavior is steer (the default), so the most common send path still hits the error.
Repro (observed on v0.1.1, Windows, Claude provider)
From the server trace and the provider event log for one thread:
02:11:29.777Z: runordinal:10starts after a user message.02:11:32.676Z: user sends a follow-up.message.dispatch→Orchestrator.dispatchSteerIntoRunfails withOrchestrationV2DispatchCommandError: No running provider turn found for active run run:thread:…:ordinal:10.02:11:33.434Z: first native event from the Claude provider for that turn.
The follow-up stays in the composer and the user has to resend it.
Cause
In CommandPolicy resolveDeliveryIntent, explicit steer (and restart) return before the gap check that #15691 added:
if (deliveryIntent === "steer") return { type: "steer_active", targetRunId: activeRun.id };
if (deliveryIntent === "restart") return { type: "restart_active", targetRunId: activeRun.id };
if (activeRun.status === "preparing" || activeRun.status === "starting" ||
!projection.providerTurns.some((t) => t.runAttemptId === activeRun.activeAttemptId && t.status === "running"))
return { type: "queue_after_active" };Expected
An explicit steer that arrives while the active attempt has no running provider turn shouldn't be rejected. It should be queued and delivered to the next or just-starting turn, as auto now is. From the user's side, steering a run that is just about to start and queueing for that run look the same.
Suggested fix
Apply the gap check to steer as well as auto: return queue_after_active when the run is preparing/starting or the active attempt has no running provider turn. Leave restart as it is. Add a steer row to the existing gap table in CommandPolicy.test.ts (absent, pending, completed, previous-attempt running).
Activity
markshan00 commentedon Oct 27, 2026
Adding a matching macOS observation, with sanitized timing evidence that may help with the startup-gap case. Thanks for tracking this down.
Environment: macOS desktop, a locally localized build
0.1.2-zh.1based on upstreamv0.1.2, using the Claude provider withclaude-opus-5-5. This was observed during normal use, not a synthetic stress test.Two occurrences were correlated using server spans, the provider protocol log, and read-only run/provider-turn projections. Times below are relative to each run's recorded
startedAt; identifiers, message contents, paths, account configuration, and absolute timestamps are omitted.Orchestrator.dispatchSteerIntoRunBoth rejections reported:
For sample A, the original prompt was offered to Claude at +12.912 s. The
GitVcsDriver.checkpoints.captureCheckpointspan insideRunExecutionService.startRootRuntook 12.890 s, including a Git subprocess taking 12.796 s. The original run subsequently completed; the rejected follow-up remained in the composer. Sample B's original run also subsequently completed.This supports a concrete way the startup gap becomes user-visible for seconds: the run is already recorded as running while baseline checkpoint capture is still pending, before the Claude provider turn exists. I have not investigated why those checkpoints were slow, so I am not attributing that to repository size or a particular Git operation.
The upstream
v0.1.2source matches the issue's diagnosis: explicitsteerreturns before the no-running-provider-turn check, whereasautoqueues. The web composer can send that explicit intent while the run reads as running.This is additional evidence for the reported failure only. I have not runtime-tested either proposed fix (#23559 or #25749) on this machine. No raw logs or screenshots are attached, to avoid exposing private workspace and conversation data.
ebrardushullovcii commentedon Oct 28, 2026
Same bug here, T3 Code desktop on Windows 11 with the Claude provider (Opus 5.5).
How I hit it: a scheduled automation posts a message into the thread, which starts a new run. If I send a message shortly after, it shows for under a second, then "No running provider turn found for active run run:thread:import:claudeAgent:...:ordinal:721." appears and the message goes back to my composer. Retrying fails the same way until the turn actually starts streaming.
Two details that may help:
bramtechs commentedon Nov 1, 2026
Another way to hit this: with an ACP provider (Antigravity), the turn restart caused by one steer leaves a gap of about a minute, and any steer sent during it is rejected.
Environment: Windows 11 desktop, server at
9e09926d, Antigravity provider (claude-opus-4-6-thinking).What happened:
ordinal:4starts with a user messageNo running provider turn found for active run …:ordinal:4.Three retries failed the same way.Why this gap is longer: ACP adapters report
supportsActiveSteering: falseandsupportsSteeringByInterruptRestart: true(packages/provider-acp/src/server/adapter.ts). Steer #1 therefore takes the interrupt-restart path indispatchSteerIntoRun. That path movesrun.activeAttemptIdto the new attempt right away. The new attempt's provider turn only exists once the adapter has stopped the old ACP prompt and Antigravity has started the new one. The run reads asrunningthroughout, so the composer keeps offering Steer. During that time the check atOrchestrator.ts(providerTurns.find(t => t.runAttemptId === targetRun.activeAttemptId && t.status === "running")) finds nothing.Both open fixes key on "the active attempt has no running provider turn", so #23559 and #25749 should cover this case as well. Nothing extra seems needed. I'm adding this because the gap here comes from a steer restarting the turn, not from run startup or completion, and it lasts much longer with ACP providers than the 1–3 s seen with Claude.
I have not tested either PR against Antigravity.
Written by Claude Code (Claude Opus 5.5) at the reporter's request.
jamesdchen commentedon Nov 2, 2026
Still reproduces on v0.1.6 (desktop, Windows), on a thread hosted on a linked/remote environment reached through the T3 Connect relay.
2026-11-02T03:06:09Zand03:06:14Z(client trace): two sends to the remote thread both failed inEnvironmentCommands.startThreadTurn→orchestration.dispatchCommandwithOrchestrationV2DispatchCommandError: No running provider turn found for active run run:thread:<id>:ordinal:5.followUpBehavioris"queue", not the defaultsteer. So the refusal isn't limited to the explicit-steer path described above, unless the client still sendsdeliveryIntent: "steer"in queue mode.03:07:52Z, the relay reported the remote environment disconnected. It hadn't come back by03:15Z, though the host was reachable over Tailscale. So the remote run may also have been stuck inrunningwith no provider turn, rather than in a short start/finish gap. I couldn't check the remote server's side.Expected: the follow-up is queued for the active run, or the run is reconciled, not dropped from the composer with this error.
🤖 Generated with Claude Code
ducktaperules commentedon Nov 6, 2026
Current-nightly occurrence with 24 hours of supporting evidence
Sending a message while a Claude run is starting can fail with
No running provider turn found for active run .... T3 has already marked the run asrunning, but has not yet recorded a root provider turn for its active attempt. Repeated sends fail until that provider turn appears.Adding current-nightly evidence to this open report. The older automatic-delivery report #15600 was closed; our captured failures reach the steering dispatcher described here. We did not capture the outgoing
deliveryIntentor clientfollowUpBehavior, so those settings are not asserted. The roughly 30-second gap also resembles #28996, but checkpoint timing was not investigated in this collection.Environment
0.1.8-nightly.20261106.4262.0.1.8-nightly.20261106.4262.claudeAgent; model:claude-opus-5-5.Observed behavior
The send fails instead of being queued until the provider is ready. Failed commands have persisted
status = rejectedreceipts and no orchestration events under their command IDs. The existing runs subsequently complete successfully.Today's exact error:
The server stack places this error in
Orchestrator.dispatchSteerIntoRun, throughOrchestrator.dispatchMessage,orchestrationV2.dispatch.once,orchestrationV2.dispatch.withReceipt, andThreadMessageIntake.dispatchCommand. The Windows client records it asOrchestrationV2DispatchCommandErrorinEnvironmentCommands.startThreadTurn.Evidence from the last 24 hours
Window: 2026-11-05 12:24:18 UTC to 2026-11-06 12:24:18 UTC, fixed at the start of the investigation.
There are 68 distinct rejected
message.dispatchcommand IDs across six runs in two threads. This is a count of rejected commands, not a count of independent root-cause incidents or duplicate trace spans.running, but there is no root provider turn for its active attempt. These are corroborating instances; their exact error text is no longer available.All times below are UTC. Thread labels omit conversation titles and repository names.
All six runs have an approximately 30-second startup gap. All recorded rejections fall within that gap. This suggests a useful reproduction window, but the reason for the delay has not been established.
Detailed current occurrence
For thread B, run 14 on 6 November:
11:48:07.089: run and active attempt markedrunning.11:48:17.896-11:48:32.975: 12 different message commands rejected with the exact error. All 12 have zero resulting orchestration events.11:48:37.163: first rootprovider-turn.updatedevent withstatus = running; itsstartedAtis11:48:37.155.11:49:03.714: the original run completes.Example rejected command:
34a6b465-bf55-4a42-9fc8-2fcf0428d753. Representative trace records are included below. The other eleven rejects have different command IDs, so these failures are not simply replays of one rejected command ID.Expected behavior
A normal send during provider startup should remain queued or otherwise be accepted for delivery when the provider is ready. A temporary absence of a provider turn should not make the message fail.
Reproduction guidance
Based on the captured failures, start a Claude turn and try sending another message while T3 shows the run as running but before its first root provider turn appears. The observed window was about 30 seconds in all six affected runs. This is a proposed reproduction based on captured state, not a newly executed controlled test.
Collection and limits
The investigation used read-only SQLite connections (
mode=ro,query_only=ON) and existing trace files. It did not send messages, restart T3, change settings, or modify application state.Rejected commands came from
orchestration_command_receipts. The generic receipt error alone does not establish the exact cause. Run and provider-turn state were reconstructed by replaying the relevant application-version-2 events fromorchestration_eventsin sequence order through each receipt'sresult_sequence. Matching provider turns were restricted to the run's active attempt and root node. The reconstructed lifecycle event was checked to precede the rejection timestamp, and the first matching provider-turn event was checked to follow it.The 56 older rejected commands are in five bursts on one thread. Today's 12 are on a second thread. All six runs used Claude Opus 5.5 and later completed. Exact errors were retained only for today's case: the collected Ubuntu trace files have no spans older than 08:39 UTC on 6 November. Older rejections therefore must not be described as 56 independently confirmed occurrences of the exact error text.
The evidence below excludes message text, conversation titles, repository names, credentials, and raw stack file paths. It retains command IDs, opaque run IDs, source filenames and line numbers, timestamps, and selected state fields. Source logs rotate; filenames and line numbers refer to the collection snapshot.
The full per-command export is retained locally and can be provided if needed.
Representative sanitized server and client trace records
These describe the first of the 12 confirmed rejected commands. Nested spans are not counted as separate sends.
{ "server": { "file": "server.trace.ndjson.2", "line": 1654, "timestamp": "2026-11-06T11:48:17.893Z", "span": "Orchestrator.dispatchSteerIntoRun", "trace_id": "f5878903c02419efdc8737db56a72c8d", "command_id": "34a6b465-bf55-4a42-9fc8-2fcf0428d753", "run_id": "run:thread:mcp%3Alaunch%3A0772fba6206ce86e6781c85f4be18d7c9771d893872efc2efa23023407fcf753:ordinal:14", "error": "No running provider turn found for active run run:thread:mcp%3Alaunch%3A0772fba6206ce86e6781c85f4be18d7c9771d893872efc2efa23023407fcf753:ordinal:14.", "version": null }, "client": { "file": "server.trace.ndjson.5", "line": 9062, "timestamp": "2026-11-06T11:48:18.361Z", "span": "EnvironmentCommands.startThreadTurn", "trace_id": "874c1a99fc7389403228f81155ade099", "command_id": null, "run_id": "run:thread:mcp%3Alaunch%3A0772fba6206ce86e6781c85f4be18d7c9771d893872efc2efa23023407fcf753:ordinal:14", "error": "No running provider turn found for active run run:thread:mcp%3Alaunch%3A0772fba6206ce86e6781c85f4be18d7c9771d893872efc2efa23023407fcf753:ordinal:14.", "version": "0.1.8-nightly.20261106.4262" } }Prepared with Codex (
gpt-6.1-sol) at the reporter's request.jackroberts236 commentedon Nov 6, 2026
Additional confirmed occurrence on macOS desktop, local server,
0.1.8-nightly.20261106.4262, usingclaudeAgent/claude-opus-5-5. This includes a completion → queued subagent-result wake-up → provider-startup handoff, with “always steer” enabled according to the reporter.The reporter saw a follow-up remain queued as the parent finished, then a citation-containing send was refused with:
A citation-containing message was subsequently accepted. The captured failure occurs in
Orchestrator.dispatchSteerIntoRun, rather than citation lookup.Correlated evidence (6 November 2026, UTC)
Existing server/client traces, effect-outbox records and read-only lifecycle events show:
waiting. Its post-turn checkpoint capture took about 30.1 seconds and timed out.running, before its provider turn existed. Baseline checkpoint capture then took 30.042 seconds and failed; the server continued without a baseline.message.dispatchcommands were refused with the error above, targeting that wake-up run.A later Claude run repeated the startup gap: run marked running at 14:20:20.581, steer refused at 14:20:38.995, provider turn started at 14:20:45.607. This time baseline capture took about 24.99 seconds and failed with
VcsProcessExitError/ Git exit 128, rather than a timeout.A separate Codex thread on the same install also showed repeated refusals between its run being marked running at 14:20:49.054 and its first provider turn starting at 14:21:36.206. This supports a shared orchestration gap rather than a Claude- or citation-only failure.
Fix scope
The latest published nightly checked during triage,
0.1.8-nightly.20261106.4275(6577c6b6185167c0e502fa01f9e8e8f2dee6ff25), still resolves explicitsteerbefore checking whether a running provider turn exists. See the release's CommandPolicy. This is source verification, not a claim that the incident was reproduced on that newer build.Identifiers, conversation text and filesystem paths are omitted. Evidence collection used existing logs and SQLite connections opened with
mode=ro; no live database writes were made.Prepared with Codex (
gpt-6.1-sol) in T3 Code, at the reporter's request.