Repository navigation
[Bug]: Working section unfolds for seconds (sometimes stuck) after switching back via macOS Stage Manager #29031
Description
Before submitting
- I searched existing issues and did not find a duplicate. (Related open PR: fix(web): alt-tabbing back no longer flashes Working threads into the sidebar list #28909, which has no linked issue.)
- I included enough detail to reproduce or investigate the problem.
Area
apps/web (seen in the macOS desktop app)
Steps to reproduce
- On macOS, turn on Stage Manager and put T3 Code in its own stage.
- In T3 Code, turn on Settings → Working section and leave the Working section collapsed.
- Have several threads running, so they are folded under "Working".
- Click another app in the Stage Manager strip, then click T3 Code to bring it back.
Expected behavior
Running threads stay folded in the collapsed Working section when T3 Code comes back to the front.
Actual behavior
Every time T3 Code comes back from another stage, every running thread drops out of the Working section into the main list, then folds back in after a few seconds. If I switch away and back again before it settles, the threads are still unfolded when I return.
Sometimes they never fold back in. Turning the Working section setting off and on doesn't fold them back either.
Switching apps without Stage Manager doesn't seem to trigger it for me. My guess is that Stage Manager actually hides the window when you switch stages, which fires visibilitychange, while a plain Cmd-Tab leaves the window visible.
This looks like the regression described in #28909: since #26195, isSidebarEnvironmentDisconnected treats a connected environment whose shell isn't live as disconnected. Each application-active wakeup (from visibilitychange) resubscribes the shell and sets it to synchronizing, so all Working threads leave the shelf until synchronized arrives. If that resync is slow or never reaches live, the threads stay unfolded, and the setting can't change that. #28909's rule (keep the previous verdict while the socket stays connected) should cover both the flash and the stuck case. This report adds the macOS Stage Manager trigger, a much longer window than the ~300 ms measured there, and the stuck variant.
Impact
Minor bug or occasional failure
Version or commit
0.1.7-nightly.20261101.4048 (88f6113)
Environment
macOS 26 (Darwin 25.5) with Stage Manager on, T3 Code desktop app (nightly), local environment
Workaround
Wait for the resync to finish. When it gets stuck, nothing I've tried in the UI folds the threads back in.
Activity
GoatXYZ commentedon Nov 2, 2026
Also seeing this in the web client at app.t3.codes in Microsoft Edge when switching browser tabs.
Environment
157.0.4341.36(64-bit).0.1.7-nightly.20261102.4093.Reproduction
Expected: running threads stay beneath the Working header when returning to the tab.
Actual: the running rows briefly move into the main list, then return beneath Working. They still display their Working labels during the movement, and the selected thread's elapsed counter continues increasing. No shelf toggling is involved in these cycles.
Recording
20261102-2046-52.1087769.mp4— approximately 3.2 seconds.The clip captures three switches away from and back to T3, followed by the repeated row movement. The browser address bar is cropped out to avoid exposing the URL's identifiers. Each captured jump recovers on its own.
Relation to the proposed fix
This appears consistent with the foreground-resync explanation in PR #28909: returning to the tab starts a shell resync, and the sidebar temporarily treats the connected environment as disconnected while its shell is not yet live. The proposed fix preserves its previous disconnected status during that resync, which should prevent the temporary move out of Working.
This adds an external-browser case to #29031. The recording confirms the repeated visual behavior, but does not expose the shell or connection state. I haven't tested the patched build, and this clip doesn't show the persistent/stuck variant described in the original issue.
Prepared with GPT-6.1 Sol through the Codex harness in T3 Code, using the user's recording and read-only source investigation.
Terrigible commentedon Nov 4, 2026
Also seeing this on Windows when restoring a minimized window.
Version: T3 Code Desktop 0.1.7 (stable), local server 0.1.7. The relevant code is unchanged on
mainas of 2026-11-05.Environment: Windows desktop app, server running on Linux under WSL2.
Steps:
Actual: every time, the working thread animates from the main list into Working on restore, with no change in thread status.
Expected: the thread stays in Working with no movement.
Diagnosis: this matches the path described above: the restore fires
visibilitychange, theapplication-activewakeup resubscribes the shell, and thesynchronizingstatus makesisSidebarEnvironmentDisconnectedreturn true untilsynchronizedarrives. The animation seen on restore is the thread's move back to the shelf. Traced in the v0.1.7 source, not reproduced by the agent. The server trace shows repeatedsubscribeShellrestarts, but has no client-side events to tie them to a restore.Triaged by Claude Opus 5.5 (Claude Code, running inside T3 Code).
juliusmarminge commentedon Nov 9, 2026
Thanks for the report. #31269 (34701646) removes the connection and shell-sync gate, so working threads stay in the Working shelf through disconnects and resynchronization.