Repository navigation
[Bug]: Finished or input-waiting threads stay stuck in the mobile Working shelf #24901
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 the current Android nightly (Working shelf beta on):
- Start a thread so it appears in the Working shelf.
- Let the run finish, or reach a point where the agent asks for input (approval or user input).
- Watch the Home list.
Also reproducible by switching to another app and back while a run finishes.
Expected behavior
A thread that stops working, or that starts waiting on approval/user input, moves out of the Working shelf into the normal visible section right away (input-requesting threads immediately, finished threads after the 2s grace from #24760).
Actual behavior
The thread stays in the Working shelf indefinitely, still shown as working. Collapsing/expanding the shelf, or anything that rebuilds the list, unsticks it. Once stuck it stays stuck because no further events arrive for that thread, so nothing re-renders the list.
Impact
Minor bug or occasional failure
Version or commit
Regression window: 0.1.3-nightly.20261024.3643 (fine) -> 0.1.3-nightly.20261025.3655 and 3669 (stuck). Introduced by #24760 (242d00c), likely interacting with the render-skipping from #24646 (62eb35b).
Environment
Android app (internal APK, versionName 2.1.0 build 464) on Android 15, connected to a remote T3 server on Linux.
Logs or stack traces
No crash; this is a client state bug. Reading the code: createInboxReturnTracker (packages/client-runtime/src/state/threadInbox.ts) only marks a thread as exited during observe(), and observe() re-runs from useThreadListV2 only when the threads array identity changes or the tracker version bumps. After a run's last shell update the array identity stops changing. When the grace timer fires it bumps the version and observe() re-runs, but with the same stale threads closure, so isThreadWorking on the stale shell (runtime still "running") returns true again and re-affirms working: true with no deadline. The exit is reverted and no further timer is armed, so the thread never leaves the shelf. navigationThreadShellsAtom (packages/client-runtime/src/state/threadShell.ts) returning the previous array when arrayElementsEqual contributes to the stable identity.
Workaround
Collapsing and re-expanding the Working shelf (or switching tabs) forces a rebuild and unsticks the rows.
Activity
ilyakam commentedon Oct 30, 2026
Same thing. I couldn't find a thread last night. This morning I noticed it was stuck under "Working." See attached:
Environment
Android app (internal APK, versionName 2.2.0) on Android 17, connected to a remote T3 server on Linux.
playcations commentedon Oct 31, 2026
I ran into this too and traced the finished-thread case to the Working list's memo. The React Compiler dropped the grace version from its dependencies, so the list only rebuilt when another thread updated. Fix: #28169.
I didn't find a cause for threads waiting on input or approval staying in Working: those don't depend on the grace timer, so that part may need a separate look.
kaovilai commentedon Nov 4, 2026
confused why #24907 is closed..
imluckii commentedon Nov 6, 2026
I have no clue. Will have my agent look into why that PR got closed
VDrozd-Cyclis commentedon Nov 9, 2026
Still observed on iPhone app 2.2.0 with macOS desktop and a remote Linux server, both 0.1.7. Clearing both environment caches, fully closing/reopening the app, and toggling Working section off/on did not resolve it. The manual update check reports Up to date.
At 13:09 CET on November 9, an idle conversation shows a plain timestamp but remains inside Working, while another row reflects a newly started run. Earlier screenshots show a completed conversation with Done still inside Working. Host inspection confirmed that run completed with no active run; its lastVisitedAt was later than completion. The server answered the phone’s shell snapshot request with HTTP 200 during the incident.
This supports stale section membership despite some updated row data. The user also reports stale status/read badges. The exact cause and installed JS update revision remain unknown; this is not confirmation of a regression after #28169.
Phone licenses: effect/@effect/atom-react 4.0.5, expo-updates 58.0.17, react-native-screens 5.0.0-t3.48.
No deterministic trigger or verified workaround yet. Host-side investigation was read-only.
Investigated by Codex (GPT-6.1-Sol) in T3 Code.
Screenshots
Mobile version and update-check evidence
Original screenshots from the start of triage
playcations commentedon Nov 9, 2026
The fix in #28169 merged November 1, after the current App Store release, 2.2.0, was published on October 28. That original store build therefore does not include this fix, so this may still be the original bug rather than a regression.
T3 supports compatible OTA updates, but delivery of this particular fix to the App Store build has not been confirmed. The “Up to date” result alone does not establish which JavaScript revision is running.
There is a related report in #32350: iOS 2.2.0 (202) was missing another November 1 change while also reporting “Up to date”; that report was closed while waiting for its release to the installed app.
Sources: merged fix, App Store version history, related report’s closing comment.
juliusmarminge commentedon Nov 12, 2026
This is the same problem as #28169, so I'm closing it in favour of that one. If it is different, say how and it will be reopened.