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 time label's slot and grey, 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). Before, the waiting row had no label at all. After, it reads "Waiting on 2 subagents". The row's accessibility label read "Launch Slow Test and Review Agents, 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), five 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.

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 9ee0da3

Macroscope's review found this PR approvable — This is a localized waiting-row presentation and accessibility fix that reuses existing task-state logic and does not change execution, persistence, defaults, or workflow behavior. The shared formatter is covered for the relevant task combinations, keeping the change bounded across web and mobile.

No code changes detected at 70b883a. Prior analysis still applies.

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

[coderabbitai]

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: 2c4ca7f8-cb62-4c0d-9b06-aa003b36ed08

📥 Commits

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

📒 Files selected for processing (3)

• apps/mobile/src/features/threads/thread-list-v2-items.tsx
• apps/web/src/components/Sidebar.tsx
• packages/client-runtime/src/state/threadExecution.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 8 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: ➖ Normal

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

Change: Bug fix

Suggested reviewers: juliusmarminge

Merge Risk: ⚪ Minimal · up to 70b88

The changed rows show task-aware waiting statuses, and no actionable merge-blocking issue is established by the review evidence.

Security Architecture Review

Security architecture risk: ⚪ Minimal · up to 70b88

The change presents existing task information in thread rows without granting additional access or execution authority. The reviewed paths preserve existing thread selection and completion behavior; no material security risk was found.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The changed path expands where existing task descriptions are displayed within the corresponding thread row. It introduces no task lookup, child-thread navigation, service access, or execution authority through the waiting-status result.

Trust Boundaries and Controls

• observed — Mobile rows continue to receive thread shells through the existing navigation selection pipeline. The waiting presenter consumes pending tasks from that supplied shell, and card/slim row presses still select the same thread. The change adds no identity transition or permission decision; upstream snapshot authorization remains outside this assessment.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Description check	⚠️ Warning	The description covers the problem, change, scope, and verification. However, the Scope and approval section states that maintainer sign-off has not been received, and it does not provide an approved …	Add a link to the triaged issue or discussion with explicit maintainer approval of the direction and scope, including the approval comment. If the change qualifies as a small, focused fix of an obvious bug, explain why it qualifies for that…

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Approvability	✅ Passed	PASS. The diff changes waiting-row labels and accessibility text in the web and mobile clients, adds a shared presentation helper, and adds focused tests. It does not change settings defaults, static-…
Title check	✅ Passed	The title clearly and concisely describes the main change: waiting rows now say what task they are waiting on.

Full details: Description check

Explanation

The description covers the problem, change, scope, and verification. However, the Scope and approval section states that maintainer sign-off has not been received, and it does not provide an approved discussion or explain why this change qualifies for the small, obvious-fix exception.

Resolution

Add a link to the triaged issue or discussion with explicit maintainer approval of the direction and scope, including the approval comment. If the change qualifies as a small, focused fix of an obvious bug, explain why it qualifies for that exception instead.

• 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

---

_{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