fix(clients): waiting rows say what the task waits on

[saphid]

Problem

With the Working section on, a thread parked on background work reads only "Waiting" on web and shows nothing at all on mobile. The section already says the task is underway; the row does not say what it is waiting on. Is it two subagents, a monitor, or a test run? You have to open the thread to find out, and "Waiting" next to a thread that is about to wake looks the same as one that will sit for 40 minutes.

Change

The section answers "is my task still underway?" The row answers "what is happening?"

• A waiting row names the work that will wake the agent, using the same words as the composer strip: "Waiting on 2 subagents", "Waiting on Review src/math.ts", or "Waiting on 1 subagent and 1 monitor". On web it shows that work's icon (bot for a subagent, eye for a monitor, terminal for a command, clock for other background tasks). On mobile it uses the status label style from feat(mobile): fade working threads and match web's status labels #17368, in grey with the icon the work log uses for that kind of work (sparkles for a subagent, terminal, eye, clock), and the row's VoiceOver label includes it.
• Only work that holds completion is named, via the existing backgroundWorkHoldsCompletion. A dev server left running next to a subagent is not listed, and a thread with only a dev server left stays out of Working, as it does today.
• On hover, the label fades out inside the status slot instead of sweeping over the project name. The hover fade used to pin only the label's right edge, which a long waiting label overflowed (reported by @mwolson).
• Section placement does not change. When a held-command signal like feat: Wait keeps a thread working until its background command ends #15315 lands, a command the agent waits on gets "Waiting on " with a terminal icon through the same predicate, with no change here.

One helper, presentWaitingRowStatus in client-runtime, feeds both clients. It reuses presentPendingBackgroundWork, so the row and the composer strip cannot drift.

Scope and approval

This is a proposal for the open question in #15433 (and the "Waiting" label in #15099): keep one Working section, and put the waiting detail on the row instead of deciding placement with it. I have not had maintainer sign-off on the direction. The proposal and these screenshots are posted for that decision in #15433 (comment). If you would rather not take it, close this and I'll drop it.

It does not change which threads count as working, so it is independent of #15413 and composes with #15315.

Verification

Live run on an isolated dev server (fresh state, Claude Opus 5.5 turns, Working section on). The same live threads are captured with main's row code swapped in by hot reload (before) and with this branch (after).

Web sidebar. "Launch UI Test Fixture Agents" is waiting on two background subagents. "Background Agent UI Test" is waiting on a monitor and two background commands; only the monitor is named. "Run Slow Benchmark Fixture" is the main agent working. "Start Local UI Test Server" only left a dev server running and stays in the inbox.

Before (main) / After (this PR)

When the subagents finished, the thread left Working and returned to the top of the inbox as Done:

After the subagents finish

Mobile thread list (iOS Simulator, iOS 26.5, on main after #17368). Before, the waiting row fades but shows no label at all. After, it reads "Waiting on 2 subagents" with the subagent icon. The row's accessibility label read "Slow Test Fixture Delegation, Waiting on 2 subagents" in an AgentDevice snapshot.

Before (main) / After (this PR)

Hover fade (web). Frames below freeze the 150 ms fade at full opacity to show where the label sits while it fades. Measured on the hovered row: before, the slot spanned x 154–237 but the label spanned x 77–237, over the project name (x 40–148). After, the label stays within the slot (x 174–237). The resting layout is unchanged (label x 77–237 in both).

Checks:

• vp test run packages/client-runtime/src/state/threadExecution.test.ts apps/web/src/components/Sidebar.logic.test.ts: 191 passed on the rebased head. New cases cover a single named item, grouped counts led by subagents, and that commands left running are not named (including a dev server next to a monitor, and a dev server alone).
• tsc --noEmit in packages/client-runtime, apps/web, and apps/mobile: no errors. vp lint on the changed files: no new warnings.
• Independent review: GPT-6.1 Sol (high), six rounds. Round 1 found that the mobile VoiceOver label left out the new detail; fixed in the second commit. Round 2 had no findings. Round 3 checked the rebase onto main, where this meets native /goal (feat: native /goal for Codex and Claude, with goal status in the UI #15592), and had no findings. Round 4 checked the hover-fade fix across every status, focus, and snooze-menu state and had no findings. Round 5 checked the rebase onto the auth permission changes (feat(auth): separate environment administration permissions #9786) and had no findings. Round 6 checked the mobile label rebuilt on feat(mobile): fade working threads and match web's status labels #17368's status label design and had no findings.

Not checked: Android, the desktop app shell (it renders the same web sidebar), and a held command, which needs #15315.

Claude Opus 5.5 via Claude Code in T3 Code.

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Approved at 9b20dcb

Macroscope's review found this PR approvable — This is a localized UI/accessibility fix that names the existing background work a waiting thread is already tracking, with corresponding truncation and unit-test coverage. It does not change thread execution, scheduling, defaults, schemas, or deployment behavior.

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

[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: c5987175-9625-4e5d-a4ed-80be3b25127e

📥 Commits

Reviewing files that changed from the base of the PR and between 70b883a and 9b20dcb.

📒 Files selected for processing (2)

• apps/mobile/src/features/threads/thread-list-v2-items.tsx
• apps/web/src/components/Sidebar.tsx

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

---

📝 Walkthrough

Walkthrough

Waiting thread rows on web and mobile now show status labels derived from pending background tasks. The shared presenter filters tasks that do not hold completion and returns a label and kind. Tests cover its output.

Changes

Waiting row status

Layer / File(s)	Summary
Derive and test waiting status packages/client-runtime/src/state/threadExecution.ts, packages/client-runtime/src/state/threadExecution.test.ts	presentWaitingRowStatus filters tasks that do not hold completion and returns a label and kind for qualifying tasks. Tests cover single tasks, grouped tasks, running commands, and empty results.
Render waiting status in thread rows apps/web/src/components/Sidebar.tsx, apps/mobile/src/features/threads/thread-list-v2-items.tsx	Web rows display task-specific waiting labels and icons, with constrained status text and clipping in the described cases. Mobile rows display waiting status ahead of the unread “Done” label or timestamp, constrain waiting-status text, and include waiting status and queued-message information in accessibility labels.

Priority: ⬇️ Low

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

Change: Bug fix

Suggested reviewers: flamboh

Merge Risk: ⚪ Minimal · up to 9b20d

Waiting rows gain task-specific labels while retaining the existing completion semantics and generic fallbacks. No concrete merge-blocking behavior is established.

Security Architecture Review

Security architecture risk: ⚪ Minimal · up to 9b20d

The change displays task information already available to each thread row. The inspected changes do not add task execution, permissions, or access to other threads, and no material security risk was identified.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The changed client data flow is bounded to task information already supplied for the displayed thread. It introduces additional presentation exposure, but no cross-thread lookup or new authority-bearing operation was identified in the changed consumers.

Trust Boundaries and Controls

• inferred — For the inspected label flow, potentially untrusted task descriptions remain display data rather than becoming markup, commands, navigation targets, or permission inputs. This conclusion concerns the changed client sinks, not independent verification of server-side authorization.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
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.
Title check		The title clearly and concisely describes the primary change: waiting rows now state what task they are waiting on.
Description check		The description includes all required sections. It clearly explains the problem, implementation, scope, approval context, verification steps, evidence, and unchecked areas. It also states that maintai…

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

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

---

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

[jlipworth]

Hit this on iOS with Claude (Opus 5.5) threads. The parent's turn ends while subagents keep running, and the thread looks idle in the thread list. Opening it shows the "Waiting on…" pill.

On main, resolveThreadListV2Status already returns "waiting" for these threads (apps/mobile/src/features/threads/threadListV2.ts:200). But STATUS_LABEL_BY_STATUS in thread-list-v2-items.tsx:65 has no waiting entry, so the row falls back to the timestamp and looks like a resting thread. The comment at threadListV2.ts:73 says waiting should read "grey like working rather than a false Done", so this looks like a missing renderer rather than intended behavior. This PR fixes it. +1 for landing it.

[saphid]

Review requested

Date (UTC)	Reviewer	Where
2026-10-06	Julius	Discord DM

_{Logged so this PR shows when a maintainer was asked to review it.}

[mwolson]

I see a bit of animation strangeness where upon hovering with a long enough subagent name, the name briefly expands to full width of the card before disappearing; so far I haven't seen any other existing parts of the card do this.

screenrecording-2026-10-06_14-28-35.mp4

[saphid]

Thanks, reproduced and fixed in 9ee0da3.

On hover the status label leaves the flow and fades out under the row actions, but only its right edge was pinned. A long "Waiting on …" label kept its full width, so for the length of the fade it covered the project name. Short labels like "Working 3m" barely move, which is why nothing else on the card showed it. The fading label is now clipped to the status slot. Measured on a hovered row: the label used to span x 77–237 over a slot of x 154–237; it now stays within x 174–237. The resting layout is unchanged.

Dismissing prior approval to re-evaluate 9ee0da3

Dismissing prior approval to re-evaluate 9b20dcb