[Bug]: Live sidebar updates move row action targets under the pointer

[MaximilianMauroner]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/desktop

Steps to reproduce

Reported by Max during normal use; the timing-dependent interaction has not been independently reproduced by the filing agent.

1. Open T3 Code with several threads visible in the left sidebar.
2. Move the pointer toward an action on a particular thread row, such as Snooze or Settle.
3. While preparing to click, let a new thread appear or an existing thread leave the visible list.
4. Observe the remaining rows shift. An action for another thread can now occupy the position the pointer was targeting.

The affected action examples above are illustrative; no specific wrong-thread mutation was independently verified.

Expected behavior

Live updates should preserve the intended action target during interaction. A row changing position should not cause an action intended for one thread to apply to another.

Possible approaches include deferring row movement during interaction or canceling a click when its target changes. These are suggestions, not a prescribed implementation.

Actual behavior

Max still sees threads move when new threads arrive or existing threads leave the sidebar. This creates a risk of clicking an action on a different thread than intended.

Impact

Interaction reliability issue: live list movement can change the target of a thread action.

Version or commit

0.0.46-nightly.20261004.2644
Release commit: 7379933

Environment

T3 Code desktop on macOS.

Related work

• fix(web): stop sidebar rows flashing and shifting on click #10713, merged and included in this nightly, fixes unnecessary animations and focus-scroll shifts on click.
• fix(web): fix thread jumping after reorder #7103, merged and included in this nightly, fixes an extra animation after manually reordering pinned threads.

The reported movement still occurs with those fixes present. This report concerns live insertion/removal changing action targets.

Screenshots, recordings, or supporting files

No public capture of the timing-dependent interaction is attached; the supplied screenshot shows the sidebar layout but does not demonstrate the movement.

Workaround

No verified workaround.

Opened on behalf of Max by GPT-6.1 Sol using Codex in T3 Code.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Triage

Thanks for writing this up, @MaximilianMauroner. It's a real mis-click risk in the web sidebar, which the desktop app embeds, and it's still present on current main. No open issue covers it. #10713, #7103, and #15418 are related but don't fix this case.

What I found

• The sidebar is a live list. When a thread enters or leaves a section, sidebarListOrderKey changes and createSidebarListMotion slides the remaining rows over 150 ms (apps/web/src/components/Sidebar.motion.ts). Motion only pauses while a row is being dragged (listMotionPaused = dragState !== null in Sidebar.tsx), so hovering a row or aiming at Snooze or Settle doesn't hold the list still.
• Snooze and Settle appear on hover, and each handler is tied to its own row's thread (handleSettleClick calls onSettle(threadRef), and snooze works the same way). After a row above appears or disappears, the control under a still pointer belongs to a different thread, and a click acts on that thread. A sweep gesture is exposed the same way, because sidebarThreadKeyAtY reads the live layout.
• fix(web): stop sidebar rows flashing and shifting on click #10713 stopped the list animating on every shell update and scrolling under a click, but real order changes still animate. fix(web): fix thread jumping after reorder #7103 was the extra jump after a manual pin reorder. fix(clients): Working section keeps its order while agents finish and wake #15418 landed after your nightly and keeps the Working section in last-user-message order, so finished runs no longer reshuffle it. Threads still shift their neighbors when one is created or leaves a visible section (settled, snoozed, archived, or returning to the inbox).
• I didn't capture a wrong-thread click in a running client, but the source path matches what you describe.

Likely fix area

• apps/web/src/components/Sidebar.tsx and Sidebar.motion.ts. Both ideas in the report fit: defer order changes while the pointer is over the list, or ignore a click when the thread under the pointer isn't the one it entered on. Mobile uses its own list and doesn't have this hover-action path.

A short screen recording would help with priority, though it isn't needed to confirm the mechanism. A maintainer will decide on the fix direction.