Repository navigation
[Bug]: Mobile tool-call group stops following new calls, so the newest rows end up out of view #15704
Description
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/mobile
Steps to reproduce
- On iOS, open a thread whose turn is running and keeps producing tool calls, so the expanded tool-call group is taller than its scroll area.
- Expand the group and scroll it to its last row.
- Keep your finger off the screen while the turn adds more calls.
Expected behavior
While the group is scrolled to its end, new calls stay in view: the group follows them, as shouldFollowThreadWorkGroupAppend intends.
Actual behavior
The group stays where it was. New calls are added below the visible area, so the newest rows are hidden and the group's scroll indicator is no longer at the bottom.
In the recording, the group is at its end at 0:12. Over the next 16 s the turn adds 5 rows, and the group's scroll offset stays at 1831 pt while its content grows from 2116 pt to 2261 pt. Dragging again at 0:28 reveals them, and the next call is missed the same way. It also happens when the offset is exactly at the end: in a separate run the offset stayed at 1048 pt while the end moved from 1048 pt to 1193 pt. Offsets were read from the accessibility tree.
On my iPhone, during a long Claude turn, the group was in the same state, with its scroll indicator about 5 rows above the bottom, and I could not drag it any further. In the simulator, dragging again does reach the new end.
Impact
Minor bug or occasional failure
While following a running turn on mobile, the newest tool calls are the ones that go out of view.
Version or commit
Reproduced on main @ 4ee6bfd. Also seen on T3 Code iOS 2.0.0 (103).
Environment
Reproduced: iPhone 17 Pro Max simulators on iOS 27.2 and iOS 26.5, development client, isolated local server with a scripted fake agent (no model calls) that streams reasoning and a tool call about every 3 s. Also seen: iPhone 17 Pro Max, iOS 27.2 (24B5089g), T3 Code 2.0.0 (103), Claude turn running for about 7 minutes.
Screenshots, recordings, or supporting files
All project and thread data in the recording is synthetic.
work-group-follow.mp4
Source pointers
The follow rule is shouldFollowThreadWorkGroupAppend in thread-feed-live-follow.ts, used by ThreadWorkGroupList in thread-work-log.tsx. Why it does not fire here has not been investigated. #9359 and #10212 fixed earlier sizing bugs in the same component.
Activity
juliusmarminge commentedon Oct 4, 2026
Note
Grok responding on behalf of Julius.
Triage
Thanks for the careful measurements, @nekohasekai. They made the follow path much easier to trace. #9359 and #10212 already fixed height and clipping in this list. The follow behavior is a separate problem.
What I found
I checked this against
main(4ee6bfd50e).ThreadWorkGroupListdecides whether to follow inside the LegendListtotalSizelistener. It only callsscrollToEndwhenshouldFollowThreadWorkGroupAppendreturns true.useLayoutEffect. LegendList emitstotalSizefrom its ownuseLayoutEffect, and child layout effects run before the parent's. So the listener still sees the previous render'sactivities.maintainScrollAtEnd. The mobile list never setsmaintainScrollAtEndand depends on a singlescrollToEndcall instead.Likely fix area
onContentSizeChangeinapps/mobile/src/features/threads/thread-work-log.tsx. One option is to make the follow decision from the activities of the render that added the rows, before the new content height is recorded.maintainScrollAtEndfor that append instead of callingscrollToEndaftertotalSize.A maintainer will decide on the fix direction.