Before submitting
Area
apps/mobile (iOS)
Steps to reproduce
- In a Claude (Opus 5.5) thread, have the agent start background subagents and end its turn while they run.
- Go back to the thread list.
Expected behavior
The row shows that the thread is still underway, like the grey "Waiting" label in the web sidebar.
Actual behavior
The row shows only its timestamp, the same as a finished, idle thread. Opening the thread shows the "Waiting on…" pill, so the app knows it's waiting.
Impact
From the list you can't tell a thread that's still working through subagents from one that's done.
Version or commit
iOS app 2.0.0 (109). Source checked on main at 68e50db.
Root cause
- The status is derived correctly.
shellRuntime parks a thread at idle when subagents hold its completion (packages/client-runtime/src/state/models.ts:176-202). resolveThreadListV2Status then maps that to "waiting" (apps/mobile/src/features/threads/threadListV2.ts:200).
- But
STATUS_LABEL_BY_STATUS (apps/mobile/src/features/threads/thread-list-v2-items.tsx:65) has no waiting entry. The row falls back to the timestamp at line 968.
- The comment at
threadListV2.ts:73 says waiting should read "grey like working rather than a false Done", so the renderer is missing, not deliberately left out.
- Web handles it with a grey "Waiting" label (
apps/web/src/components/Sidebar.tsx:1268).
Suggested fix
Render waiting on mobile. The minimal version adds a waiting entry to STATUS_LABEL_BY_STATUS that matches web. Open PR #16213 goes further and names what the thread waits on ("Waiting on 2 subagents"). It covers this and is mergeable.
Related: PR #15413 and discussion #15433 cover the wider question of which background work should keep a thread in the Working section. This bug is narrower: with the Working section off (the default), a waiting thread has no visible status on mobile at all.
Workaround
Open the thread to see the "Waiting on…" pill.
Before submitting
Area
apps/mobile (iOS)
Steps to reproduce
Expected behavior
The row shows that the thread is still underway, like the grey "Waiting" label in the web sidebar.
Actual behavior
The row shows only its timestamp, the same as a finished, idle thread. Opening the thread shows the "Waiting on…" pill, so the app knows it's waiting.
Impact
From the list you can't tell a thread that's still working through subagents from one that's done.
Version or commit
iOS app 2.0.0 (109). Source checked on
mainat68e50db.Root cause
shellRuntimeparks a thread atidlewhen subagents hold its completion (packages/client-runtime/src/state/models.ts:176-202).resolveThreadListV2Statusthen maps that to"waiting"(apps/mobile/src/features/threads/threadListV2.ts:200).STATUS_LABEL_BY_STATUS(apps/mobile/src/features/threads/thread-list-v2-items.tsx:65) has nowaitingentry. The row falls back to the timestamp at line 968.threadListV2.ts:73says waiting should read "grey like working rather than a false Done", so the renderer is missing, not deliberately left out.apps/web/src/components/Sidebar.tsx:1268).Suggested fix
Render
waitingon mobile. The minimal version adds awaitingentry toSTATUS_LABEL_BY_STATUSthat matches web. Open PR #16213 goes further and names what the thread waits on ("Waiting on 2 subagents"). It covers this and is mergeable.Related: PR #15413 and discussion #15433 cover the wider question of which background work should keep a thread in the Working section. This bug is narrower: with the Working section off (the default), a waiting thread has no visible status on mobile at all.
Workaround
Open the thread to see the "Waiting on…" pill.