fix(mobile): stop background work after the turn settles

[tris203]

After a turn completes, background tasks can keep running while mobile has no way to stop them. Add a separate Stop action to the existing “Waiting on…” pill, preserving the composer draft.

Fixes #14655. Replaces #14661 with the requested interaction evidence. Rebased onto main at c77a7b7eeb.

V2 implementation

Use the existing pendingBackgroundTasks / presentPendingBackgroundWork model and its task labels. The thread-only shared interrupt command resolves the settled run with pending work and sends V2 run.interrupt; no server, contract, or provider changes are needed.

Stop is one more segment of the existing pill, built like the agents and queue segments beside it; the status label itself is unchanged from main. It is hidden when the client lacks the orchestration operate scope.

Pending behavior now matches V2 web: Stop is disabled as Stopping… while the interrupt request is pending. It becomes available after acceptance or failure if tasks remain visible; acceptance is not proof of termination. The pill disappears when the pending-task roster clears. This deliberately replaces the previous V1 implementation's “disabled until liveness clears” behavior.

Request state is scoped to the environment/thread and the individual request, so an older completion cannot clear a newer request. Only the separate Stop button interrupts work. Existing status priority, queue/agent/device controls, and foreground-turn Stop behavior are preserved. Long task labels truncate while Stop remains visible.

Approval and scope

• Maintainer-approved direction in #14655.
• #14661 closure confirms approval and identifies missing interaction evidence: retain a draft, establish pending behavior, and demonstrate failure recovery. The fresh recording below tests the V2 pending semantics described above.

Three mobile files. Web/desktop already provide this path. Shared iOS/Android code; native verification is Android/Claude only. Other providers retain their existing interrupt semantics. iOS and relay/tunnel were not device-tested.

Evidence

Current layout

Android 16 Pixel emulator against an isolated worktree-local server, on head 7c1360cd5f (main at c77a7b7eeb plus this change). A real Claude Sonnet 4.6 session started each piece of background work and completed its turn.

Command left running (sleep 3600 with run_in_background=true). Tapping Stop ended the sleep, cleared the pill, and left the draft in place.

Stop segment beside the task label, draft in the composer	After Stop: pill cleared, draft retained

running-stop.mp4

Work the agent is waiting on (a monitor described as "Evidence file ready"). The middle image is a frame from the recording below, taken while the interrupt was in flight.

Stop beside the waiting label	Stopping… while the interrupt is pending	After Stop: pill cleared

bolt-stop.mp4

Connection without operate permission (paired with orchestration:read only). The pill names the running work and has no Stop segment.

Not captured on the current layout: a failed interrupt and retry (see below), Stop alongside the queue, agents, or preview segments, and iOS.

Pending and failure behavior (earlier layout)

The material below was recorded before Stop became a pill segment. The Stop text sat in a separate label component then; the request handling it exercises is unchanged. The retry and failure states have not been re-recorded on the current layout.

Android 16 Pixel emulator, compatible current development client, V2 main plus this change. A fresh worktree-local .t3 and manufactured project/thread were created through server commands; no live user data was copied. A real Claude Sonnet 4.6 session started sleep 3600 with run_in_background=true, completed its turn, and left a command in pendingBackgroundTasks. No separate runtime prerequisite patch was needed.

Before: V2 waiting pill without Stop	After: Stop beside the same task label and draft

22-second continuous recording, normal speed, with explanatory captions:

verification-v2.mp4

Original recording without captions.

A test-only WebSocket proxy rejects the first interrupt with OrchestrationV2DispatchCommandError. On retry it forwards the real interrupt, holds the successful response and subscription updates separately, then releases each. This makes the transient states observable without modifying production code or fabricating task completion.

Recording	Observed result
0–3s: failed request	Stop becomes available for retry; task and draft remain.
3–13s: retry pending	Stopping… is disabled (enabled: false in the native tree). The extra tap sends no new interrupt: count remains 2 total, including the rejected attempt.
13–20s: acceptance delivered	Stop is enabled again (enabled: true) while the task roster is still held. This is the V2 web behavior.
20–22s: task update delivered	The pill disappears. The server projection confirms an empty pending-task roster and the run remains completed.
Throughout	Keep this draft while stopping background work. stays unchanged.

Checks

• Mobile typecheck passed.
• 331 mobile thread-feature tests passed on the current head; client-runtime thread execution and shared V2 pending background work tests passed on the previous rebase.
• Targeted lint: no errors; the same 30 warnings as main, compared ignoring line-number shifts.
• Formatting and git diff --check passed.

Implemented and verified with GPT-6-Astra through the Codex harness in T3 Code. Rebased, reworked to reuse the pill's segment UI, and re-verified with Opus 5.5 through the Claude Code harness in T3 Code.

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — This PR adds a new mobile Stop action that can terminate background tasks after a turn settles, invoking an existing interrupt path with meaningful runtime effects. The change is localized and access-controlled, but the new user-facing capability warrants human review.

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

Dismissing prior approval to re-evaluate d8abb52

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Path: .coderabbit.config.ts
• Review profile: CHILL
• Plan: Advanced
• Run ID: f4cfb05f-f89a-4e80-9146-081096331bb4

---

---

---

📥 Commits

Reviewing files that changed from the base of the PR and between 4ddc3e3 and 98c205b.

---

---

---

📒 Files selected for processing (3)

• apps/mobile/src/features/threads/ThreadDetailScreen.tsx
• apps/mobile/src/features/threads/ThreadRouteScreen.tsx
• apps/mobile/src/features/threads/floating-working-control.tsx

---

---

---

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

---

---

---

---

📝 Walkthrough

📝 Walkthrough

📝 Walkthrough

Walkthrough

The mobile thread screen now offers a Stop control for background work. The route sends an interrupt for the selected thread and tracks the request state until the call settles.

Changes

Mobile background-work stopping

Layer / File(s)	Summary
Background-stop request and state propagation apps/mobile/src/features/threads/ThreadRouteScreen.tsx, apps/mobile/src/features/threads/ThreadDetailScreen.tsx	The route tracks stop requests for the selected thread, sends an interrupt without a run ID, and clears the matching request when the call settles. The thread screen passes the stop state and callback to the floating control when the thread can be operated.
Floating background status control apps/mobile/src/features/threads/floating-working-control.tsx	The background status displays a Stop control when a stop action is available. The control displays “Stopping” and is disabled while stopping. Its width is measured and deducted from the status-label space.

Priority: ➖ Normal

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

Change: Feature · Severity of issue fixed: Medium

Sequence Diagram(s)

sequenceDiagram
  actor User
  participant FloatingWorkingControl
  participant ThreadRouteContent
  participant ThreadInterrupt
  User->>FloatingWorkingControl: Press Stop
  FloatingWorkingControl->>ThreadRouteContent: Invoke stop callback
  ThreadRouteContent->>ThreadInterrupt: Interrupt selected thread without run ID
  ThreadRouteContent->>ThreadRouteContent: Clear matching request when call settles

Loading

Suggested reviewers: juliusmarminge

---

---

---

---

Merge Risk: ⚪ Minimal · up to 98c20

This adds a Stop control for background work in mobile threads. No concrete merge-blocking defect was established. One open question remains: whether a rejected interrupt call could leave the button showing "Stopping" until the user switches threads. The author could confirm this cheaply.

Security Architecture Review

Security architecture risk: 🔵 Low · up to 98c20

The new action preserves existing operation permissions and selected-thread targeting. Stop is thread-wide, not limited to one displayed task, and request acceptance does not guarantee termination. Downstream isolation and termination behavior remain only partially verified.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• observed — The observed action scope is thread-wide rather than task-specific: it holds queued work, can interrupt pending work across multiple provider threads in the selected thread's projection, and can disable its visible pull-request watches. These outcomes do not demonstrate isolation between authenticated environments or tenants.

Trust Boundaries and Controls

• observed — The server authenticates the WebSocket upgrade, installs authorization using that session's scopes, and requires orchestration:operate before dispatchCommand executes. The operation is therefore not protected solely by a mobile UI permission check.
• observed — The server loads the command thread's projection, validates its run and provider-thread references, and derives provider effects from that projection. This establishes target routing, not independent authenticated thread ownership or provider-specific authorization; those portions of the supplied proof gaps remain unresolved.

Resilience and Maintainability Implications

• observed — Commands serialize per environment/thread, limiting concurrent client transitions in the same scope. Pull-request-watch updates are nevertheless sequential rather than an atomic group, so partial acceptance can leave some watches unchanged. The UI permits retry after settlement, but backend duplicate effects and eventual provider termination were not established.

---

---

---

Pre-merge checks | 3 | 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Linked Issues check		The PR implements the mobile Stop action and sends a thread-only interrupt for settled background work [#14655]. It preserves the draft and permits retry after a failed request. However, #14655 requir…	Keep Stop disabled as “Stopping…” until the pending background-task roster or equivalent background liveness clears. Clear the state after request failure only when retry must be available.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Out of Scope Changes check		The reported changes are limited to four mobile files. They add the background Stop control, thread interrupt handling, state propagation, and layout support for the objective in #14655. No unrelated …
Title check		The title clearly and concisely describes the main mobile change: enabling users to stop background work after a turn settles.
Description check		The description covers the problem, implementation, scope and approval, verification results, UI evidence, limitations, and agent details. It is complete and aligned with the required template.

---

Full details: Linked Issues check

Explanation

The PR implements the mobile Stop action and sends a thread-only interrupt for settled background work [#14655]. It preserves the draft and permits retry after a failed request. However, #14655 requires Stop to remain disabled as “Stopping…” until background liveness clears. The implementation clears the stopping state when the interrupt request settles, so it re-enables Stop while pending work remains visible.

---

• Fix all pre-merge checks with AI

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

---

---

---

---

---

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

Autopilot is currently an internal CodeRabbit preview.

---

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

Dismissing prior approval to re-evaluate 2e31bf9