[snnbotchway]

Problem

When a Claude turn is waiting on AskUserQuestion and another thread sends it a message with the default auto mode (t3_thread_send, or the attachment send tool), the user loses their place in the question. Answers already picked and text being typed disappear, and Claude asks the question again from question 1.

Change

auto delivery steers into the active turn when the provider supports steering. Claude declares activeSteeringInterruptsTools: true. Its steer cancels the pending canUseTool callback, so ClaudeAdapterV2 withdraws the user_input request (cancelWithdrawnRequest). The client then prunes that request's drafts in onThreadRequestsResolved, and Claude re-asks under a new request id.

resolveDeliveryIntent now queues automatic delivery while the thread has a pending runtime request, so the message runs after the user answers. Approvals are covered too, because a steer withdraws them the same way. An explicit steer or restart still goes through as asked, and so does a message the user sends themselves.

Scope

This is a small fix for an obvious bug: typed input is lost with no action from the user. It needs no issue. It is one condition in the delivery policy, and it is provider-agnostic. Providers whose steer leaves pending requests alone (Codex) now queue in this state too. That is harmless, because the turn cannot move until the user answers anyway.

Verification

• I hit this as a daily user. I was answering a 3-question AskUserQuestion while another thread used t3_thread_send on mine, and the panel reset to 1/3 with my answers gone.
• I traced it through ThreadManagementService.sendToThread (auto → steer_active), resolveDeliveryIntent, ClaudeAdapterV2.steerTurn (a priority: "now" message), the AskUserQuestion branch of canUseTool (the abort signal leads to cancelWithdrawnRequest), and the web onThreadRequestsResolved pruning.
• I added CommandPolicy.test.ts cases for a pending user_input request and a pending command request. Both failed on main with steer_active and pass with the fix. They also assert that an explicit steer still steers.
• CommandPolicy, SteeringCompletion.integration, ThreadManagementService, runtimeLayer, ThreadLaunchService, ThreadStop, ProviderSwitch.integration and OrchestratorMcpService suites pass, and vp run check:changed passes.
• I did not run a live Claude turn against the patched server.

Opus 5.5 (Claude Code, driven from T3 Code)

[macroscopeapp]

Approvability

Verdict: Needs Human Approval

Macroscope's review found this PR requires human approval — Automatic delivery now queues messages while a question or approval is pending, rather than interrupting the active interaction. Human confirmation is needed for this change to the automatic delivery policy.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review.

Walkthrough

When a runtime request is pending, automatic delivery now queues after the active run. Tests cover pending user_input and command requests, and confirm that explicit "steer" delivery still targets the active run.

Changes: Pending runtime request delivery

Layer / File(s)	Summary
Pending request delivery policy and tests apps/server/src/orchestration-v2/CommandPolicy.ts, apps/server/src/orchestration-v2/CommandPolicy.test.ts	resolveDeliveryIntent queues automatic delivery when a runtime request is pending. The test projection includes an empty runtimeRequests collection, and tests cover pending user_input and command requests as well as explicit "steer" delivery.

Estimated code review effort: 2 (Simple) | ~8 minutes

Change: Bug fix

Possibly related issues

• pingdotgg/t3code#26841 — The issue describes automatic delivery steering into a pending request; this change queues automatic delivery when a runtime request is pending.

Possibly related PRs

• pingdotgg/t3code#26842 — This PR also changes delivery behavior for pending runtime requests, but covers explicit steering and promoted queued messages as well.

Suggested labels: bugfix

Suggested reviewers: juliusmarminge, t3dotgg, macroscopeapp

Merge Risk: Minimal · up to 47ab4

Automatic messages from other threads now wait until the active run finishes when a question or approval is pending, so a half-answered question is no longer wiped. Explicit steer and restart and the web composer's user sends behave as before. No concrete merge-blocking risk remains in the reviewed change.

Pre-merge checks: 4

Check name	Status	Explanation
Title check		The title names the main change: a message from another thread no longer wipes a half-answered question. The changeset makes automatic delivery queue while a runtime request is pending, which prevents…
Description check		The description follows the template sections: Problem, Change, Scope, and Verification. The Problem section gives the bug, expected behavior, and trigger. The Change section explains the steer, withd…
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

Full details: Title check

Explanation

The title names the main change: a message from another thread no longer wipes a half-answered question. The changeset makes automatic delivery queue while a runtime request is pending, which prevents the steer that withdraws the AskUserQuestion request. The title is specific and matches the diff. It uses the conventional commit form. It is slightly long at 83 characters.

Full details: Description check

Explanation

The description follows the template sections: Problem, Change, Scope, and Verification. The Problem section gives the bug, expected behavior, and trigger. The Change section explains the steer, withdrawal, and queueing logic. The Scope section explains why no issue is linked and why the change is a small bug fix. The Verification section lists focused tests, observed failures on main, and a stated gap (no live Claude turn). The model and harness are named at the end. The description does not link an issue, but it gives a reason for that, as the template allows. The description is mostly complete.

Finishing Touches

Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Recent review info

Run configuration

• Source mode: Auto
• Repository: pingdotgg/t3code
• Branch: main
• File: .coderabbit.config.ts
• Commit: cc97303
• Layers: Repository TS config
• Review profile: CHILL
• Plan: Advanced
• Run ID: b2bc8651-02e3-4bfc-8f1e-691d86a0b5cd

Commits

Reviewing files that changed from the base of the PR and between cc97303 and 47ab408.

Files selected for processing: 2

• apps/server/src/orchestration-v2/CommandPolicy.test.ts
• apps/server/src/orchestration-v2/CommandPolicy.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

[snnbotchway]

Note

Claude Opus 5.5 responding on behalf of @snnbotchway.

Closing as a duplicate of #26842, which fixes the same bug (#26841) on more paths: composer steers and promoted queued messages too. I added my reproduction and failing test there.