Repository navigation
[Bug]: iOS does not show Monitoring status displayed on desktop and web #10372
Description
Activity
Triage
Confirmed presentation bug on current
main(223ff4490). Desktop/web already distinguish Monitoring from Working; mobile never does.backgroundLivenessis already onOrchestrationThreadShell(packages/contracts) and on the mobile thread shell. Web uses it inSidebar.logic.ts/Sidebar.tsx(list label) andChatView.tsx(open-thread “Monitoring” banner + Stop). Underapps/mobilethere are zero references tobackgroundLivenessormonitoring.Status falls through to idle/ready:
apps/mobile/src/features/threads/threadListV2.ts(resolveThreadListV2Status) — approvals, input, parentsession.status, thenreadyapps/mobile/src/features/threads/threadPresentation.ts(resolveThreadStatus) — same; no Monitoring branch- Open thread (
use-thread-composer-state.ts,ThreadDetailScreen.tsx,floating-working-control.tsx) — parent session / latest turn only
This is shared mobile code (iOS and Android), not an iOS-only renderer bug.
Not a wash duplicate
- [Bug]: Mobile looks idle while background subagents are still working #4962 — same ignored field, but
backgroundLiveness === "working"(active subagents). Web treats that as Working. This ticket is the distinct Monitoring watch/wait state. A fix that only maps"working"→ Working would leave this open. - [Bug]: Mobile thread list never shows Done after a turn completes #4952 — missing Done. Not asserted here.
- [Feature]: Mobile: sub-agent visibility parity — spawn indicator, Agents surface, and background liveness #6402 — closed broader Agents/liveness request. feat(mobile): subagent visibility with agents sheet and liveness #6616 would have added mobile monitoring and was closed unmerged. fix(web): show a thread's completion when a watch loop is still live #7655 notes mobile still does not surface
backgroundLiveness.
Suggested fix
Consume
thread.backgroundLivenessin both list resolvers and the open-thread indicator, matching web:"working"→ Working (also [Bug]: Mobile looks idle while background subagents are still working #4962)"monitoring"→ Monitoring (calm, no pulse — this ticket)null→ current ready/idle
No contract or server change required. Pin with tests: settled parent +
"monitoring"vs"working"vs idle.Labels:
bug,accepted,via-triage(removeneeds-triage)Also reproducing this on Android, so this is not iOS-specific.
- Desktop: T3 Code 0.0.40 on Windows 11 — thread shows Monitoring as expected.
- Mobile: Android app on a Pixel 9 (app version unconfirmed) — same thread shows no monitoring indicator and reads as finished.
The triage note above explains why: since
apps/mobilehas zero references tobackgroundLiveness/monitoring, andresolveThreadListV2Status/resolveThreadStatusare shared React Native code, Android falls through toreadyon exactly the same path iOS does. Nothing platform-specific is involved.Practical impact from the phone: a monitoring thread is indistinguishable from a completed one, so the last assistant message reads as the end of the turn. You put the phone down thinking the work is done while the agent is still waiting on a background run, and only find out later when it posts again. On desktop the Monitoring label makes this obvious at a glance.
Suggest widening the title/scope from iOS to
apps/mobileso the fix covers both platforms.Confirming on Android with a pinned app version, since the earlier Android report had its app version unconfirmed.
- Host/desktop: macOS 26.6.1, T3 Code desktop 0.0.40. Sidebar labels the thread Monitoring as expected.
- Mobile: Android app 1.1.0 on a Samsung Galaxy S25 Ultra. The same thread shows no monitoring indicator in the thread list.
That is a second Android device on a confirmed build, which lines up with the triage note that this is shared
apps/mobilecode rather than an iOS renderer issue — so the title'siOSscope undersells it.Worth flagging the user-facing cost from the operator side: with the label missing, the phone gives no way to tell a watching thread from a finished one, so you either walk away from live background work or go back to a laptop just to confirm the state the desktop sidebar already knows.
#10436 appears to implement exactly the fix suggested above (both list resolvers plus the open-thread indicator, with tests), and has been open since 2026-09-07 without a review decision.
Thanks for taking the time to report this and provide the details. We revisited it during the orchestrator V2 cleanup.
The V1 backgroundLiveness Monitoring state has been replaced by a shared runtime model. Both current mobile and web list resolvers map idle-with-background-work to Waiting rather than Ready, addressing the reported phone-versus-desktop completion ambiguity.
I’m closing this report because the implementation it targets has been replaced. That does not mean every similar symptom is fixed.
Does not claim every background-task status is correct; fresh V2 disagreement or open-thread presentation regression should be reproduced.
If you still hit this on a current build, please reply with the app/server versions and the steps that reproduce it. We can reopen this if the original problem is still there.
Problem and reproduction
When the same thread shows Monitoring on desktop and web, the iOS app does not show a corresponding monitoring indicator. This makes it unclear whether the agent is still watching/waiting or has finished.
Expected: iOS should visibly distinguish Monitoring from active Working and completed/idle states, consistent with desktop/web. Check both the thread list and open-thread presentation, and clear the indicator when monitoring ends.
Environment and source evidence
Observed with a Mac-hosted T3 Code environment; desktop version 0.0.38. The iOS app was recently installed/updated; its exact version/JS update is unconfirmed.
Upstream source inspected at
223ff4490f764a74ff911589e97b9bbcd595fee8:backgroundLiveness === "monitoring", separately from background subagents doing active work.ready; it does not consume background liveness.These are source observations, not confirmation of the exact code installed on the phone.
Related issues checked