Sidebar moves a remote environment's working threads into the main list whenever its connection blips#30680
What happened
With the Working shelf on and a linked remote environment over the relay, that environment's working and waiting threads keep jumping between the collapsed Working group and the main list. In one case, 3 threads left the main list and Working went from 1 to 4 within a few seconds, with no change in thread status. With about 10 active threads this happens often and pulls attention away from the work.
Diagnosis
belongsInSidebarWorkingShelf (apps/web/src/components/Sidebar.logic.ts) leaves out every thread whose environment is in disconnectedEnvironmentIds. isSidebarEnvironmentDisconnected marks an environment disconnected as soon as its phase is not connected or its shell is not live, so a short reconnect or resubscribe moves all of its shelf threads into the main list, and they move back when it recovers. The 2 s exit grace in createInboxReturnTracker (packages/client-runtime/src/state/threadInbox.ts) doesn't cover this path. Losing the connection alone isn't evidence the work stopped (same principle as #25449), so placement should stay where it was while reconnecting.
Separately: "Waiting" rows (runtime idle parked on background work, or blocked on a thread wait) count as working for the shelf on purpose (isThreadWorking), which confuses users when a row says Waiting but sits under Working.
Steps to reproduce
- Turn on the Working shelf.
- Link a remote environment over T3 Connect and run 2-3 threads there (working, or waiting on a subagent).
- Interrupt the link briefly (or let the relay return HTTP 524s).
- The threads drop into the main list, then jump back into Working when the link recovers.
Expected: a thread's placement stays stable while its status doesn't change, including during short reconnects.
Version
T3 Code Desktop (Nightly) 0.1.7-nightly.20261104.4151 (local server same build). The relevant code is unchanged on main as of 2026-11-04.
Environment
macOS 15 (Darwin 24.5.0) arm64, desktop app against a local server plus one linked remote environment via relay.
Evidence
shell
| 1 | - The 3 affected threads all live on the linked remote environment, not the local server. |
| 2 | - That environment link's last recorded error: "The linked environment answered HTTP 524." |
| 3 | - Before/after screenshots (attached below): Working group count 1 -> 4 a few seconds apart, with the same threads leaving the main list. |
Related issues
#25449 (cached rows keep claiming Working while reconnecting; same root, this one is about placement), #4589
Fix applied or workaround
Turn off the Working shelf in settings.
Filed by
Triaged by Claude Opus 5.5 (Claude Code, running inside T3 Code).
