fix(server): agent messages no longer cancel Claude tools#21158

Codex Review Summary

This comment shows the latest Codex review activity on this pull request.

Approvability

Verdict: Approved at 1b70e2f

Macroscope's review found this PR approvable — This is a small, self-contained server bug fix that prevents agent updates from interrupting Claude tool work by reusing the existing durable queue. Human steering, safe providers, explicit restarts, and existing callers remain unchanged, with targeted integration coverage added.

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

Review in Change Stack →

No actionable comments were generated in the recent review.

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

_{Comment @coderabbitai help to get the list of available commands.}

Taking over this one. I’ll reduce the tests to the useful coverage, update the implementation against current main, and verify it before publishing the changes.

Delivery choices and verification (2026-10-22)

• User steers, native default: earlier delivery, with the possibility of interrupting running work.
• User steers, safe boundary: wait for running work to finish, with additional delivery latency. This choice is the maintainer's decision; I am not recommending either option here.
• Agent steers should not interrupt work: no discarded thinking, no interrupted commands or tool calls.

Within those rules, steers should be delivered with the lowest possible latency. An agent steer should enter at the earliest safe boundary, the next tool boundary, rather than wait for the turn to end.

Open question for parallel tool batches: deliver after the first call finishes for lower latency, or after the whole batch to avoid changing context mid-batch and possibly wasting calls? The fork fix conservatively keeps whole-batch delivery without deciding this policy question.

I reviewed the current diff at d4ac7c1029; the Known limits below still apply and are not repeated here.

• Verified installed behavior: the PC runs fork.3, source 7a557e5204a4, including the tool-boundary patch; Android is stock. The screenshot's user-authored mobile message queued at 07:46:13 UTC, between the run becoming Running at 07:46:10 and its provider turn becoming steerable at 07:46:17. Stock Android represents Steer as auto; the server queues auto without a running provider turn. Inferred from this code path: a mobile Steer can become a next-turn message during this readiness gap. The original wire mode was not retained, so that is not proven for this particular send; Android also has a separate preference defaulting to Queue. This is separate from agent deferral, which still exempts user steers.
• Agent messages with attachments bypass the boundary queue and steer natively. Inferred from that code path, they retain native steering's tool-cancellation risk despite the explanatory note; the note does not prevent cancellation.
• Thinking-token preservation is unverified. The routing and delivery tests do not establish that provider-side reasoning is never discarded.

Fork follow-up: 5fd9e2b05b makes agent-initiated promotions of queued text use the same whole-batch boundary path, while human promotions stay native and each message retains its original author. It adds no timer or fallback. Local checks passed (301 server tests and 25 client/dispatch tests, scoped typecheck, lint and formatting; the Windows check:changed launcher fails with spawnSync vp ENOENT, so its relevant checks ran directly). Two independent review rounds are resolved, and full fork CI passed. The commit is on fork main and published as v0.1.2-nightly.20261021.3486.fork.3; the release workflow passed, including Windows package verification. Linux packages built, but no separate Linux verification runner is configured. The installed PC app has not been updated or tested with this release. No changes were pushed to the maintainer's PR branch.

Thanks for taking over #21158, and sorry that three more rewrites landed on fix/agent-steer-claude-tools after your takeover comment. Agents on my side kept pushing without noticing that you had taken the branch. I have stopped all pushes from them to this branch, and my fork's rules now forbid pushing to a PR branch once someone else takes it over. This comment explains why I still think the queue-only behavior has a real cost, what was wrong with my earlier hook implementation, and a smaller replacement built on top of your takeover. You or your agents are welcome to use it; every choice in it is yours to change.

Background: the original problem

On Claude sessions, a native active steer cancels the MCP tool calls in flight (a running foreground shell command is left to finish on current Claude Code). Calls already running get "The tool call was interrupted before a result was received"; calls not yet started get a tool result that reads like a user refusal ("The user doesn't want to take this action right now. STOP what you are doing"). When the steer came from another agent (an orchestrator, a sibling task, or a delegated-task completion notice), the receiving agent concludes the user rejected its action, or that it caused the failure itself. It then stops, apologizes, changes plan, or retries. If a cancelled call had side effects (a delegation, desktop and game input driven by a script), its state is now uncertain and the agent does not know to check it. Live A/B test and real incidents: this comment.

What the takeover branch does now

To be clear about authorship: the queue-only rule is my original PR's design (2fb39acb8f), which you kept; your addition is the Stop guard (ca5ee825fa, agent updates after Stop are rejected, not queued), which is correct and should stay in any version. In Orchestrator.ts (the createdBy === "agent" branch of the dispatch), an agent-authored auto or steer send to a session whose capabilities.turns.activeSteeringInterruptsTools === true becomes queue_after_active. Claude is that session (ClaudeAdapterV2.ts sets the capability to true). Delegated-task completion notices also only steer when activeSteeringInterruptsTools !== true, so they queue too.

This fixes the false refusals, because nothing is interrupted. The cost is latency, and in agent-orchestration use it is large:

1. A queued update waits for the whole active turn, not for the current tool call. Orchestrating and long-running agents keep one turn going for a long time. In my setup a Claude coordinator supervises live desktop automation, and one delegated turn ran from 19:02 to 21:54 EDT. Any update sent during that turn, including "stop, that is wrong", lands about 3 hours later as a new turn.
2. Completion notices to a Claude parent are invisible until the parent's turn ends. A Claude orchestrator that runs a long background command, or works on something else while children run, cannot react to a child finishing or asking a question. It learns about it only after its own turn ends.
3. Explicit steer is downgraded. An agent that asks for steer because the update is urgent gets a queued next turn instead. The send result says queued, but most calling agents do not change course on that.
4. The next turn can be stale. By the time the queued turn starts, the receiving agent has often finished the work the update was about, so the update arrives without context or contradicts what it just did.

What was wrong with my earlier hook implementation (the commits you dropped)

These are real defects, and they are why the replacement below is different.

1. The 5-second defer timer defeated the purpose. If no tool boundary arrived within 5 seconds, the update moved to the next-turn queue. Any command longer than 5 seconds therefore produced exactly the queue-only behavior. A live test showed it: a Claude child ran sleep 40; date, and I sent an update at +26 s. The update was not delivered at PostToolBatch or Stop; it became a separate turn after the run ended. A later fork build raised the timer to one minute, which still fails the same way for any longer command (test suites, builds, scripted runs).
2. The timer moved updates to a later point, never an earlier one. A fallback from pending to the queue can only add delay.
3. Too much machinery. About 590 code lines and 1,500 test lines: a supportsNonInterruptingAgentSteering capability, an outbox steer held open until a hook fired, deferToQueue/steeringFallbackOfRunId plumbing, outbox claim-order exceptions, a lease exemption, process-loss requeue, and Stop-time revocation by message id. You were right to drop it.

Replacement: tool-boundary delivery on top of your takeover

Commit 2418c1cdee, branch proposal/claude-boundary-delivery on my fork, parented on your head 4e1a46fdcd. It adds +201/-6 code lines and +250/-7 test lines (+160 and +236 without comments) across Orchestrator.ts, ClaudeAdapterV2.ts, ProviderContinuationService.ts, ProviderContinuationRequests.ts and orchestrationV2.ts. It keeps your queue as the source of truth and only lets a queued agent update join the running Claude turn at its next tool boundary.

Design choices, each with its alternative:

1. The hold is your durable queue. An agent update to a busy Claude turn is queued exactly as on your branch. Alternative: an outbox steer held open until a hook fires (my old approach). Using the queue removed all of the plumbing listed above, and an unclaimed update still starts the next turn, so a crash or a missing hook falls back to your behavior.
2. Delivery is a pull from the hook. The Claude root PostToolBatch/Stop hook claims queued updates through the existing ProviderContinuationRequests channel, served by the server worker, and returns them as hook context in the same turn. Alternative: pushing pending text into the adapter, which would need its own way to revoke stale updates; a pull always reads the current queue.
3. Joining reuses the existing queued-message.promote-to-steer command with an atToolBoundary flag. It sends no steer effect and keeps the running turn's model. Delegated completions are accepted in the same command; a separate command produced duplicate notifications in testing.
4. One rule decides what may join a running turn (agentUpdateWantsPromptDelivery): agent sends that asked for auto or steer delivery, plus always-wake completions and child questions. Explicit queue sends, scheduled tasks and notifications still wait for the next turn. This also covers updates sent while a turn is still starting.
5. Stop wins at the claim. A held queue or a stopped run refuses the claim. This builds on your Stop guard instead of adding a separate cancellation path.
6. Attachments steer natively with a short note ("This message came from another agent, not the user, and may have interrupted a running command; check that command's state before continuing"), because hook context carries text only. Alternative: queue them, which brings back the long delay for that case.
7. No capability flag. Only Claude has tool-cancelling steers, and it always installs the hooks. A provider without hooks never claims, so its updates simply start the next turn.
8. No timer. Alternative: steer with the note if no boundary arrives within a bound (for example 2 minutes). Rejected because a native steer cancels the MCP tool calls in flight (delegations, game actions, waits), which is the bug itself. Waits are short anyway: Claude Code returns a shell call at its time limit, so a boundary comes within minutes. An agent blocked in a long sleep while waiting for a child is better fixed in agent behavior (end the turn and let the completion wake it), as T3's own delegate instructions already say.

Known limits:

• Delivery waits for the current tool call. A shell call returns at Claude Code's time limit (2 minutes by default, up to 10) while the command keeps running in the background; an MCP call waits for its own timeout. User steers wait the same way for a running shell command. This can be changed: a timer could fall back to a native steer with the note after a bound (see choice 8), at the cost of cancelling MCP calls in flight.
• At-most-once after a claim. If the server crashes after a claim commits and before Claude reads the hook result, those updates are lost. Native steers are at least once. This can be changed to at-least-once with a moderate change (roughly 80-150 lines): the claim marks the message as delivered to its run instead of removing it, the adapter confirms it when the hook result appears in the Claude event stream, and unconfirmed claims are requeued on restart or when the turn ends. I left it out to keep this change small and can add it here or in a follow-up.
• One extra thread read per tool batch.
• Delegated completions joining at a boundary have no dedicated test yet, and child questions joined this way show in the timeline as plain agent messages.

Suggested agent-facing doc change, for you or your agents to make if you keep this behavior: the t3_thread_send description already says the running turn may take the message after its current tool call. It could add that the wait lasts as long as that call, and that an agent should not force delivery with t3_queue_promote_to_steer or restart on a Claude target, because both cancel its MCP calls in flight and a forced steer of a queued agent message gets no from-another-agent note (test B). Making agent-initiated promotes on tool-interrupting sessions use the tool-boundary path would close this in code.

Evidence

• Typecheck passes; 52/52 orchestrator tests pass on the proposal branch. Two pre-existing failures are unrelated: an MCP test with a Windows fixture path (D:\D:\...), and two tests that time out only under parallel load.
• The fork version of the same change (a03372fbee on my fork's main) passed all six upstream CI jobs on Blacksmith (run) plus 351 focused tests. It is installed as fork build 0.1.1-nightly.20261020.3411.fork.1 and passed a live retest (results).
• Earlier live test on the one-minute fork build: a Claude child ran sleep 40; date, an update sent at +26 s with t3_thread_send mode auto arrived as PostToolBatch context right after the sleep returned, in the same run, with no interruption and no extra turn. My Claude coordinator thread receives delegated-task completions the same way, between its own tool calls.

Using it

2418c1cdee is now on this PR's branch: I pushed it on top of your head 4e1a46fdcd as a plain fast-forward, with no force-push (see the note below), and all 6 checks passed on it. You or your agents can keep it, rewrite it, revert it to go back to queue-only, or move it to a follow-up PR. The fork commit is another reference. My fork keeps the boundary delivery either way.

Upstream main has since changed Orchestrator.ts and ClaudeAdapterV2.ts. Your head already conflicts with it in Orchestrator.ts, and this commit adds conflicts in ClaudeAdapterV2.ts and its test, so merging main will need those resolved. If you prefer different choices above (for example a timer, or boundary delivery for delegated completions only), tell me and I can adapt it.

@juliusmarminge, and the agent watching this PR: I pushed one commit on top of your head, as a plain fast-forward with no force-push, so none of your commits were removed:

• 2418c1cdee fix(server): Claude takes agent updates at tool boundaries, parent 4e1a46fdcd.

It is the replacement described in my comment above: it keeps your queue and your Stop guard, and adds delivery of queued agent updates at the next Claude PostToolBatch/Stop boundary. That comment lists the design choices, the alternatives and the known limits.

It is entirely optional. Keep it, rewrite it to your taste, or drop it with a revert; any of those is fine with me. I will not push to this branch again unless a real bug or regression turns up in this commit; in that case I will push a fix on top (never a force-push) and explain it here. If you want changes, a comment is enough, or just change it yourself.

Live result on an installed build. The fork's boundary-delivery commit is 2d7eef08e4, the same change as 2418c1cdee on this branch, rebased onto current upstream main. I installed it as fork build 0.1.1-nightly.20261020.3411.fork.1 (source 77677e2227), built by this run, where all checks and the Windows and Linux desktop builds passed.

Test, run from a Claude Opus coordinator thread:

1. Delegated a Claude Sonnet child whose only job was to run sleep 40; date.
2. Sent t3_thread_send mode auto to the child at about +20 s. The send result was queued, which is the takeover branch's queue path.
3. The child's command printed 11:25:26. In the same run (ordinal 1), the child quoted the update as received after the command. The command was not interrupted, and no separate turn was created (hasPendingChildRuns: false), so the hook claimed the queued message at the tool boundary.

This repeats the earlier result from my main comment, now on a build without the old timer. The same thing happens in daily use: delegated-task completions and messages from other agents reach my Claude coordinator as PostToolBatch context between its own tool calls during long turns, instead of waiting for the turn to end.

Not covered: the at-most-once window after a claim (a server crash between the claim and Claude reading the hook result), and attachments, which still steer natively with the note.

Correction and new evidence. A live A/B test and my own thread history show more precisely what a native steer cancels on Claude, and some of what I wrote earlier was wrong. I have corrected my main comment accordingly.

What a native steer cancels

MCP tool calls in flight, not a running shell command. On the current Claude Code (v2.1.304, fork build 0.1.1-nightly.20261020.3411.fork.1), a foreground Bash call ran to completion in two tests: one with a user steer from the UI, one with an agent message forced into a native steer. In both, the message arrived right after the command returned. In one older incident (2026-10-16, a user quote reply) a running Bash call was aborted, so Claude Code may have changed since.

Calls already running get "The tool call was interrupted before a result was received. It may or may not have completed on the server — verify before assuming it succeeded, and retry if needed." Calls not yet started get "The user doesn't want to take this action right now. STOP what you are doing and wait for the user to tell you how to proceed."

Live A/B test

Two Claude Haiku agents each made three parallel t3_thread_wait calls that block for 45 s. A GPT agent sent each of them the same update with t3_thread_send mode steer, a few seconds into the batch:

Real incidents (from my coordinator thread's Claude session log)

What this changes

• The fix still targets the right thing. Agent messages must not become native steers on Claude, and test A shows tool-boundary delivery avoids the cancellation while still delivering in the same turn.
• A remaining hole: t3_queue_promote_to_steer still lets an agent turn a queued agent message into a native steer. That is exactly how test B reproduced the bug, and an agent that blames itself may retry a side-effecting call (a delegation, a game action) that already ran on the server. My earlier suggested doc change recommended this path for urgent messages, which was wrong; I have removed it. Options for you: have agent-initiated promotes on tool-interrupting sessions use the tool-boundary path too, or at least warn in the tool description that it cancels MCP calls in flight.
• The wait is shorter than I said. The update waits for the current tool call, not for "hours". Claude Code returns a shell call at its time limit (2 minutes by default, up to 10) and keeps the command running in the background. An MCP call waits for its own timeout. This applies to user steers too.