Enter during streaming targets the next model sampling boundary; input during a tool call is consumed after the tool result returns. Ctrl+Q defers input to a fresh turn.
A user can redirect the continuing turn without waiting to compose a separate follow-up after the entire response path completes.
The checked sources do not establish that queued guidance aborts, revokes, rolls back, or beats an in-flight side effect to its commit point.
Interactive agents make conversation and control look deceptively similar. A user sees a command line, notices the agent moving in the wrong direction, types a correction, and presses Enter. The interface has accepted the words. The dangerous conclusion is that the system has accepted the control intent at the same instant.
Qwen Code’s steering feature improves the conversational path. It creates a defined place for new guidance inside a current logical turn. The implementation record is equally important for what it refuses to promise: it does not attempt token-level interruption. And when a tool is already running, the guidance waits until the tool result returns. The correction may be early in human time and late in effect time.
Enter steers this turn; Ctrl+Q reserves the next one
The official 23 July weekly update says a user can press Enter while Qwen Code is streaming to inject a message into the current turn. The message is queued for the next model sampling boundary. Pressing Ctrl+Q instead queues the input for the next turn. The distinction gives the operator two conversational destinations rather than treating all mid-response input as a later follow-up. source ↓
This is meaningful. Without steering, the user may have to watch a long answer complete, wait through tool activity, then issue a corrective prompt that begins another turn with another context transition. Same-turn guidance can place the correction before the model’s next decision. It can prevent additional reasoning from following a premise the user has already rejected.
That is the supported inference: lower correction latency at a model boundary. It is not a claim of instantaneous preemption. The user’s keystroke, the interface queue, the model sampler, the tool runner, and the external system do not share one atomic clock.
During a tool call, the queue waits on the result
Merged PR #7090 states that input entered during a tool call is consumed after the tool result returns and remains part of the same logical turn. The PR also states that token-level interruption is not attempted. These two facts define a control boundary: steering is delivered to later model processing; it is not described as an interrupt sent into the running tool. source ↓
Suppose a tool has begun sending a payment, deleting a resource, publishing a record, rotating a credential, or writing a database row. The operator types “stop.” Under the published queue semantics, that text can wait while the tool completes. If the tool’s irreversible boundary occurs before its result returns, the correction reaches the model after the effect.
Even a benign filesystem tool exposes the race. “Do not overwrite that file” may arrive after the write but before the tool reports success. The next model sample can respond intelligently, apologize accurately, and still be too late. A later conversational correction is not retroactive control.
Nothing in the checked record says Qwen Code claims otherwise. The error belongs to the surrounding system if it presents steering as proof of cancellation. A queue acknowledges receipt of guidance. It does not certify the state of the work that guidance concerns.
Steer, cancel, revoke, and verify are different verbs
Editorial judgment: systems handling side effects should expose four separate controls and four separately observable states. Collapsing them into one “interrupt” affordance creates ambiguity precisely when the operator needs certainty.
- 01Steer the model.
Queue new semantic guidance for a named logical turn and report when the model consumes it. Steering changes subsequent reasoning; it makes no claim about an active tool unless another control is invoked.
- 02Cancel or abort execution.
Send a defined cancellation signal to the active tool or runner, then distinguish requested, acknowledged, stopped-before-effect, and too-late states. Cancellation must be implemented by the execution path, not inferred from text.
- 03Revoke authority.
Prevent new privileged actions by invalidating the capability, lease, token, or approval on which they depend. Revocation may block a later commit even when conversational steering has not yet been consumed.
- 04Verify and receipt the outcome.
Read the authoritative target state and bind it to tool identity, timestamps, effect identifiers, cancellation state, and the steering message. Verification answers what happened; it is not replaced by a reassuring assistant response.
An emergency stop is a stronger construction than ordinary cancellation. It should default toward removing the ability to begin or commit hazardous actions, independent of model cooperation. Rollback is different again: it is a compensating operation after an effect has occurred, and some effects have no credible inverse. A system should not borrow these words unless it implements their state transitions.
The receipt must preserve the race, not smooth it away
A useful operational record has at least two clocks. The guidance clock records when input was entered, accepted into the queue, and consumed by the model. The execution clock records when the tool was authorized, invoked, reached its commit boundary, returned, and had its effect verified. If cancellation exists, its request and acknowledgement belong on the execution clock. If authority was revoked, that event needs its own effective time and scope.
The receipt should make uncomfortable orderings visible: effect committed before guidance accepted; guidance accepted before effect but consumed after it; cancellation requested but not acknowledged; tool returned an error while the external effect nevertheless committed; model reported that work stopped without an authoritative state check. These are not logging curiosities. They decide whether the operator’s correction changed reality.
Interfaces should therefore avoid a single undifferentiated “message received” indicator. “Queued for this turn” is useful and honest. “Abort requested” is a different claim. “Authority revoked” is stronger but scoped. “No effect committed” requires evidence from the runner or target system. Each state should carry a receipt identifier so incident review can reconstruct the ordering without relying on transcript tone.
Identify the logical turn, queue position, and model boundary at which the correction became visible.
Signal the tool runner or authority system and preserve whether the request arrived before the effect boundary.
Confirm the external state and join it to guidance, tool, cancellation, authority, and effect receipts.
The merged PR validates a real macOS TUI path, not every terminal
The PR reports a real bundled terminal-UI end-to-end test on macOS. That is stronger than a purely mocked interaction for the exercised path. The same PR does not report real TUI interaction validation on Windows or Linux. This is an explicit unknown boundary, not evidence that steering fails on those systems.
Terminal input behavior is platform-sensitive: key encoding, pseudo-terminal plumbing, buffering, focus, and signal handling can differ. Operators deploying across platforms should run real interaction tests for Enter and Ctrl+Q during streaming and during tools, including delayed results and side effects. Passing unit tests around the queue is not the same as demonstrating the full input path in the terminal the operator will use.
What teams should prove before treating correction as control
The following gates are editorial consequences of the checked semantics, not claims that Qwen mandates this control architecture:
- 01Mark the commit boundary.
For every side-effecting tool, identify the last moment at which abort or authority revocation can still prevent the effect.
- 02Exercise the race.
Queue guidance before, during, and after the tool’s commit point. Confirm that the interface never labels queued text as a successful stop.
- 03Test each control independently.
Prove steer, cancel, revoke, and verify with separate acceptance criteria, states, timeouts, and receipts. A missing capability must remain visibly missing.
- 04Fail closed on uncertain effect state.
If the runner cannot establish whether an action committed, present the outcome as unknown and require authoritative reconciliation before retry.
- 05Validate the deployed terminal path.
Test actual streaming and tool interaction on each supported operating system instead of generalizing the macOS real-TUI result.
What the checked record does not establish
The two official sources do not establish token-level preemption; cancellation or termination of an active tool; authority revocation; emergency-stop behavior; rollback; a guarantee that guidance arrives before an external commit; the behavior of every tool adapter; or real terminal-UI interaction validation on Windows and Linux in PR #7090. They do not establish that those capabilities are impossible or absent elsewhere. This issue did not execute Qwen Code or test a side-effecting tool.
Limit
This is a source-bounded reading of the official weekly update dated 23 July 2026 and merged PR #7090 as checked on 2 August 2026. The control vocabulary, receipt design, race tests, and acceptance gates are editorial engineering recommendations, not statements of Qwen policy or legal advice.
What would change this assessment
An official tool-cancellation contract with acknowledged states; a capability-revocation path enforced at commit time; a documented emergency-stop or rollback mechanism; receipts proving guidance and effect ordering; or real bundled-TUI end-to-end results for Windows and Linux. Each would strengthen a specific control claim. None should be silently inferred from same-turn steering itself.
A correction can reach the next thought and still arrive after the deed.