A steer returned to the queue appears delivered before its run starts#23403

What happened

A follow-up sent while a Claude turn was running appeared both as an ordinary user bubble in the transcript and in the composer's Queued panel, with Steer, Edit and Remove controls. It initially looked as though a delivered steer had left a stale queue entry. Investigation showed that the queued run had not started at the time of the screenshot: the transcript bubble appeared too early.

Diagnosis

An accepted steer creates a user turn item before the delivery effect executes. If the provider turn ends before that effect can deliver the steer, the completion fallback dispatches the message again. While the old run still blocks a new start, that dispatch queues the message and reassigns its existing turn item to the queued run with inputIntent: "queued_turn".

The shared timeline visibility rule and the SQL snapshot filter hide cancelled queued inputs, but still show inputs whose runs remain queued. Web and mobile render this retained item while the queue panel correctly shows the waiting run. Client optimistic queue entries are not the cause.

Steps to reproduce

The deterministic regression uses a fake provider rather than a live model:

1. Start a provider turn and accept a steer while holding its delivery effect.
2. Finish the provider turn before releasing the pending steer delivery.
3. Reject delivery because the native turn has ended, causing the completion fallback to dispatch the message into the durable queue.
4. Inspect the thread before draining the queued start. The message has a queued run and a visible user timeline item at the same time.
5. Drain the worker. The queued run starts and the input is delivered once.

The expected behavior is that the pending input appears in the queue until its run starts. If startup fails, the prompt should remain visible beside its failure instead of disappearing.

Version

Observed on the personal fork build 0.1.1-nightly.20261020.3411.fork.3. The affected visibility and fallback paths also exist on upstream main at 3b95e7831b.

Environment

Windows desktop, Claude Code provider. The original Node and Claude CLI versions were not recorded. The regression harness also covers a fake Codex provider.

Evidence

An indexed, read-only check of the historical database and the thread's provider log found these times on 2026-10-22, all UTC:

The retained timeline item has inputIntent: queued_turn. Its stored item timestamp is not used as proof of provider delivery. The screenshot time and affected build are supplied context; the run and provider-offer timestamps were verified from recorded data. No matching server trace record for this message remains in the retained trace rotations.

The fake-provider regression tests passed with the fork fix, and its full fork checks passed: https://github.com/Alb11747/t3code/actions/runs/39731499185. A separate upstream-only branch is being prepared so that the PR contains no fork-specific changes.

The new client-runtime regression was also run against unchanged upstream production code at 3b95e7831b. It failed with an extra item-steer in visibleTurnItems after the run became queued: expected only item-reply, received item-steer, item-reply.

Related issues

• #19736 concerns placement of the running header around a queued message. This report concerns a retained user item appearing before its queued run starts.
• #16987 concerned started queued runs missing from a bounded timeline. The new regression also protects that history-window boundary when the hidden input becomes visible again.
• #22423 concerns delivery lost after a provider crash. The input in this incident was eventually delivered; its timeline representation was premature.

Fix applied or workaround

A focused fix is already carried in the personal fork at ffa84533b9: hide queued inputs in the shared rule and SQL snapshots, restore retained inputs when their runs leave the queue, and republish retained inputs before queued startup failure so bounded clients can restore them. An upstream-only branch is being validated.

Filed by

GPT-6.1 Sol through the Codex harness in T3 Code, with Claude Opus 5.5 diagnosis and implementation and independent GPT-6.1 Sol review. This report was prepared from source, existing incident evidence and fake-provider regression tests; it is not a new live desktop reproduction.