fix(orchestrator): Keep agent output attached after a mid-turn steer

[mwolson]

Carried from another PR

• feat(orchestrator): Surface waiting background work — carried for feat(orchestrator): Surface waiting background work #4378
  feat/orchestrator-v2-background-waiting. Review it there, not here.
• fix(orchestrator): Keep agent output attached after a mid-turn steer — this
  PR.

#4378 is included because both PRs change the same continuation gate in
bufferWakeMessage. On t3code/codex-turn-mapping that gate reads
!isPendingTaskNotification && !isPendingSubagentNotification && message.type !== "result";
#4378 rewrites the surrounding region and adds an isNativeOpaqueWakeFrame
clause that holds assistant and user frames until a background-task notification
has been buffered. Written against the base alone, this PR's change would
conflict with that rewrite and, worse, would look correct in isolation while
dropping #4378's clause.

Stacking it makes the intended end state explicit: the two conditions are
additive, so a stranded assistant frame opens a continuation while #4378's
notification gating stays intact. If #4378 merges first, drop its commit from
this branch and the remaining diff applies unchanged.

Summary

Steering a Claude turn while a tool is running settles the run while the agent
is still working. The reply to the steer then has no live turn to attach to, so
it is buffered and, with nothing asking for a continuation, silently dropped:
the thread goes quiet and returns to Ready with the steer unanswered.

There are two independent defects behind that. Fixing either alone leaves a real
failure standing, so this fixes both.

Problem and Fix

Problem and Why it Happened	Fix
isClaudeActiveSteeringAbortResult matched only terminal_reason: "aborted_streaming", which the CLI reports when a steer interrupts a streaming message. A steer landing while a tool runs is queued instead and delivered when the tool result arrives, and the CLI ends that native turn with aborted_tools, answering the steer in the next one. That result did not match, so the turn finalized while the CLI kept working.	isClaudeSteeringHandoffResult recognises a handoff by delivery state: the CLI cut the turn short (aborted_streaming or aborted_tools), or the turn ended cleanly with nothing to say. Each accepted steer swallows exactly one result, so the turn still ends on the result that answers it.
A handoff leaves the turn depending on a native turn the CLI has not opened yet. Nothing else would terminalize it.	The wait is bounded. If no frame reaches the turn within 60 seconds it settles as a failure, not a quiet completion: an accepted steer that was never answered is exactly the silence this change exists to stop.
When a run terminalizes early while the query is still live, later frames go to the wake buffer, which only requested a continuation for a tracked task notification, a running subagent, or a result. Ordinary post-settle assistant text asked for nothing, so it sat in the buffer until the session recycled.	Assistant text now requests a continuation on its own. tool_use and tool_result frames stay gated: they are the model working rather than speaking, and the notification that follows them carries the wake detail.

A result carrying text still terminalizes the turn even with a steer
outstanding, and max_turns, background_requested, tool_deferred and the
hook reasons are real terminals even as an empty success. Only completed, or
an older CLI that omits the field, means another native turn is coming.

Validation

message_steering_mid_tool is a newly recorded transcript from a real session,
not a hand-written one. It captures the shape the old guard missed: subtype: success, terminal_reason: "aborted_tools", empty text, then a fresh native
turn carrying the answer. Recording it needed a steerAfter: "tool_use" mode in
the replay recorder, waitForTurnItemType on fixture steer steps so the
replayed steer waits for the tool item instead of racing the transcript, and
stream_event acceptance in the replay decoder, since every query sets
includePartialMessages and fixtures recorded before that option have none.

Each test was confirmed to fail with its half of the fix reverted:

• message_steering_mid_tool replay fixture: without the guard fix the steer's
  answer never reaches the projection.
• Steer handoff keeps the turn alive; a result that answers it still
  terminalizes; max_turns still terminalizes; the bound settles a silent turn.
• Stranded assistant text requests a continuation; post-settle tool frames
  request nothing, and a second text frame does not double-offer.

All 449 tests under apps/server/src/orchestration-v2 pass, plus vp check and
vp run typecheck.

Live-tested on a packaged desktop build. Steering during a ~60s command, the run
now stays live 65 seconds past the steer's delivery and ends only after the last
steered reply, where it previously went terminal within about 75ms of delivery.
A second steer sent while the agent is still working is accepted rather than
refused with thread_not_sendable, and 105 status samples across the turn show
one transition, running to completed, with no blank window and no rescue
continuation run. A four-step steered instruction executed in full.

Manual re-test scenarios, in the published guide at
https://nam7nt0rbtm6.postplan.dev:

• Claude · interrupt, scenario 4 (steer a long turn twice)
• Claude · interrupt, scenario 5 (Stop while steered work is running)

---

Note

High Risk
Touches core orchestration (Claude handoff, ACP carryover/continuations, runtime idle gating) where subtle timing bugs can drop agent output or show wrong thread status.

Overview
Fixes Claude steering during an in-flight tool by treating aborted_tools / aborted_streaming and empty success results as turn handoffs (with a bounded wait), and by letting post-settle assistant text in the wake buffer request a continuation so steered replies are not dropped. Adds a message_steering_mid_tool replay fixture and recorder mode for that path.

Mobile threads now derive pending background work from live projections only, show a Waiting status pill and a waiting-background feed row (pulsing dots), and stop showing Working once runtime is parked at idle during checkpoint capture.

ACP adapter gains hasPendingBackgroundWork and stricter post-settle carryover / continuation behavior (deferred terminals until attach, wake-buffer preservation, continuation ownership helpers), with a large new AcpAdapterV2.test matrix covering those races.

^{Reviewed by Cursor Bugbot for commit 18e20c3. Bugbot is set up for automated code reviews on this repo. Configure here.}

Note

Keep agent output attached after mid-turn steer by fixing ACP adapter subagent terminal projection

• Fixes a bug where agent output could be lost after a mid-turn steer by tracking and projecting subagent terminal statuses more robustly in the ACP adapter, preventing terminal state regressions and duplicate emissions.
• Adds a 60-second steering handoff timeout to ClaudeAdapterV2 so steered turns that never receive a follow-up turn settle as failed rather than hanging indefinitely.
• Introduces pendingBackgroundTasks tracking across provider threads, projected onto provider_thread.updated events and surfaced in thread shells, chat timelines (web and mobile), and sidebar/thread status pills as a 'Waiting' state.
• Adds selectInheritedBackgroundTurnItems and writeIfProviderThreadOwner to carry over and gate background turn-item updates from prior interrupted/failed/cancelled runs through the current run's event stream.
• On server restart, ProviderRuntimeRecoveryService now cancels stale background-capable turn items and clears pendingBackgroundTasks from all provider threads.
• Risk: spreading workspaceContext directly in useHandleNewThread will now throw a TypeError if the value is null/undefined instead of silently spreading an empty object.

^{Macroscope summarized 18e20c3.}

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on this repository. Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 584c9a4b-2808-440a-95f2-4bbf444787c6

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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

[macroscopeapp]

Approvability

Verdict: Needs human review

5 blocking correctness issues found. Diff is too large for automated approval analysis. A human reviewer should evaluate this PR.

^{You can customize Macroscope's approvability policy. Learn more.}

[macroscopeapp]

🟡 Medium orchestration-v2/ProviderRuntimeRecoveryService.ts:312

Waiting runs with a replayable checkpoint.capture effect are intentionally skipped from the runs list (lines 135–155) so the run survives for checkpoint replay. But the stale-item loop at line 312 only builds its exclusion set from runs, so those preserved waiting runs are not in recoveredNonterminalRunIds. Their nonterminal background-capable turn items then fall through to lines 327–336 and are marked cancelled, corrupting the live item state of a run that recovery deliberately kept resumable. The exclusion set should include the IDs of replayable waiting runs (or otherwise skip them) so their items are not cancelled.

-      const recoveredNonterminalRunIds = new Set(runs.map((run) => run.id));
+      const preservedRunIds = new Set([...runs.map((run) => run.id), ...nonterminalRuns(projection).filter((run) => run.status === "waiting").map((run) => run.id)]);

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/server/src/orchestration-v2/ProviderRuntimeRecoveryService.ts around line 312:

Waiting runs with a replayable `checkpoint.capture` effect are intentionally skipped from the `runs` list (lines 135–155) so the run survives for checkpoint replay. But the stale-item loop at line 312 only builds its exclusion set from `runs`, so those preserved waiting runs are not in `recoveredNonterminalRunIds`. Their nonterminal background-capable turn items then fall through to lines 327–336 and are marked `cancelled`, corrupting the live item state of a run that recovery deliberately kept resumable. The exclusion set should include the IDs of replayable waiting runs (or otherwise skip them) so their items are not cancelled.

[mwolson]

The control flow is accurate, but the impact reads the opposite way round, so I am not making this change.

Recovery runs after provider process loss. The waiting run is preserved so its replay-safe checkpoint.capture can still finish, which is what the exclusion at lines 135-155 is for. Its in-flight background work is a different matter: the provider process that owned those tasks is gone, so nothing will ever complete them. Cancelling their nonterminal turn items is the cleanup that keeps them from being counted as pending forever, which would otherwise leave the thread showing "Waiting on background task" for work that died with the process.

Adding those runs to recoveredNonterminalRunIds would preserve the items rather than the run's resumability, and the checkpoint replay does not depend on them.

One note on where this belongs: this file is not part of this PR. The branch temporarily carries #4378's commit underneath its own so the two changes to the same continuation gate can be reviewed together, and this line comes from that commit.

[macroscopeapp]

Sorry, I'm unable to act on this request because you do not have permissions within this repository.

[macroscopeapp]

🟡 Medium orchestration-v2/RunExecutionService.ts:1019

After a superseded (non-finalized) root terminal, rootTerminalAlreadySeen flips root provider_thread.updated writes from writeIfRunCurrent to writeIfProviderThreadOwner. A replacement attempt in the same run shares the same run ordinal, so the stale attempt still passes expectedLastRunOrdinal and overwrites provider-thread snapshots from the active replacement attempt. Keep writeIfRunCurrent (or stop ingestion) for superseded attempts instead of switching to run-ordinal ownership.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/server/src/orchestration-v2/RunExecutionService.ts around line 1019:

After a superseded (non-finalized) root terminal, `rootTerminalAlreadySeen` flips root `provider_thread.updated` writes from `writeIfRunCurrent` to `writeIfProviderThreadOwner`. A replacement attempt in the same run shares the same run ordinal, so the stale attempt still passes `expectedLastRunOrdinal` and overwrites provider-thread snapshots from the active replacement attempt. Keep `writeIfRunCurrent` (or stop ingestion) for superseded attempts instead of switching to run-ordinal ownership.

[macroscopeapp]

🟡 Medium orchestration-v2/RunExecutionService.ts:119

selectInheritedBackgroundTurnItems returns inherited background turn item routes, but the current run's active-background-tracking set is initialized empty rather than seeded with these IDs. When the current run terminates before any inherited item emits a new non-terminal update, ingestion sees zero active background items and closes the subscription. The inherited item's later terminal event is then dropped, leaving its projected row permanently running. Seed the current run's active background tracking from the IDs returned by selectInheritedBackgroundTurnItems so ingestion stays pinned until every inherited item reaches a terminal state.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/server/src/orchestration-v2/RunExecutionService.ts around line 119:

`selectInheritedBackgroundTurnItems` returns inherited background turn item routes, but the current run's active-background-tracking set is initialized empty rather than seeded with these IDs. When the current run terminates before any inherited item emits a new non-terminal update, ingestion sees zero active background items and closes the subscription. The inherited item's later terminal event is then dropped, leaving its projected row permanently `running`. Seed the current run's active background tracking from the IDs returned by `selectInheritedBackgroundTurnItems` so ingestion stays pinned until every inherited item reaches a terminal state.

[macroscopeapp]

🟡 Medium orchestration-v2/RunExecutionService.ts:139

selectInheritedBackgroundTurnItems grants the current run routing permission for a non-terminal background item whose prior run is settled but whose ingestion subscription is still active. When the item eventually completes, both the prior run's route (matched by runId) and the inherited route accept the same turn_item.updated, so ProviderEventIngestorV2 writes the logical completion twice with separate domain-event IDs. Inheritance should only be granted once the prior route can no longer own delivery, or the persistence path must deduplicate by item identity.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/server/src/orchestration-v2/RunExecutionService.ts around line 139:

`selectInheritedBackgroundTurnItems` grants the current run routing permission for a non-terminal background item whose prior run is settled but whose ingestion subscription is still active. When the item eventually completes, both the prior run's route (matched by `runId`) and the inherited route accept the same `turn_item.updated`, so `ProviderEventIngestorV2` writes the logical completion twice with separate domain-event IDs. Inheritance should only be granted once the prior route can no longer own delivery, or the persistence path must deduplicate by item identity.

[macroscopeapp]

🟡 Medium lib/threadActivity.ts:595

deriveThreadWorkingStartedAt falls back to the shell runtime when detailStatus is cached or synchronizing, but still passes the stale detail's latestRun to deriveActiveWorkStartedAt. When the cached projection has no run while the shell runtime is active, the helper returns null and the feed shows no Working row for ongoing work; when the cached projection contains an older run, that old run's startedAt is used to timestamp the new active work. The shell runtime must be paired with the shell's corresponding latest run (or the matched activeRunId) so the fresher activity signal has matching run metadata.

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/mobile/src/lib/threadActivity.ts around line 595:

`deriveThreadWorkingStartedAt` falls back to the shell runtime when `detailStatus` is `cached` or `synchronizing`, but still passes the stale detail's `latestRun` to `deriveActiveWorkStartedAt`. When the cached projection has no run while the shell runtime is active, the helper returns `null` and the feed shows no Working row for ongoing work; when the cached projection contains an older run, that old run's `startedAt` is used to timestamp the new active work. The shell runtime must be paired with the shell's corresponding latest run (or the matched `activeRunId`) so the fresher activity signal has matching run metadata.

[macroscopeapp]

🟡 Medium orchestration-v2/RunExecutionService.ts:1081

shouldStopProviderEventIngestion catches all errors from hasPendingBackgroundWorkForThread and treats them as false (no pending work). After a completed root with no tracked turn items, a transient probe error causes takeUntilEffect to close the subscription even though the thread still has background roster work. The later provider_thread.updated clear event is never ingested, leaving the persisted pending-work/Waiting state stale indefinitely. Consider logging the probe failure and defaulting to true (keep stream open) on error so transient failures don't prematurely close the subscription.

-                .hasPendingBackgroundWorkForThread(latestProviderThreadSnapshot)
-                .pipe(Effect.catchCause(() => Effect.succeed(false)));
+                .hasPendingBackgroundWorkForThread(latestProviderThreadSnapshot)
-                .pipe(Effect.catchCause(() => Effect.succeed(false)));
+                .pipe(
+                  Effect.tapError((cause) =>
+                    Effect.logWarning("hasPendingBackgroundWorkForThread probe failed", { runId: input.run.id, cause })
+                  ),
+                  Effect.catchCause(() => Effect.succeed(true))
+                );

🤖 Copy this AI Prompt to have your agent fix this:

In file @apps/server/src/orchestration-v2/RunExecutionService.ts around lines 1081-1083:

`shouldStopProviderEventIngestion` catches all errors from `hasPendingBackgroundWorkForThread` and treats them as `false` (no pending work). After a completed root with no tracked turn items, a transient probe error causes `takeUntilEffect` to close the subscription even though the thread still has background roster work. The later `provider_thread.updated` clear event is never ingested, leaving the persisted pending-work/Waiting state stale indefinitely. Consider logging the probe failure and defaulting to `true` (keep stream open) on error so transient failures don't prematurely close the subscription.

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 18e20c3. Configure here.}

[cursor]

Handoff silence bound never rearms

Medium Severity

boundSteeringHandoff arms a single 60s check against turnFrameCounts, and any later SDK frame permanently disarms it without starting another bound. Frames that do not terminalize the turn — such as background_tasks_changed or a dropped zero-turn task-notification result — still bump the counter, so an unanswered steer can leave the run stuck in Running until the session recycles.

Additional Locations (2)

• apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts#L3834-L3851
• apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts#L4023-L4041

 

^{Reviewed by Cursor Bugbot for commit 18e20c3. Configure here.}