Repository navigation
[Bug]: iOS new thread defaults to a disconnected environment when a project exists on multiple machines #17213
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
- Have the same project/repo on two machines, both paired with the iOS app.
- Take one machine offline so its environment shows disconnected; keep the other connected.
- In the iOS app, start a new thread for that project.
Expected behavior
When only one of the project's environments is connected, the new thread defaults to that environment. When several (or none) are connected, keep the current ordering.
Actual behavior
The new thread often defaults to the disconnected environment, so I have to manually switch to the connected machine every time before starting.
Impact
Minor bug or occasional failure (constant friction for anyone with the same project on two machines)
Version or commit
iOS app 1.4.1
Related
- [Bug]: New-thread picker targets an offline grouped checkout despite a connected alternative #11359 / fix(web): Cmd+Shift+N stalls while the selected remote computer is reconnecting #10548: same issue in the desktop new-thread picker
- [Bug]: New Chat project picker is scoped to the selected chat and a disconnected remote copy does nothing #12093: web new chat fails when the selected copy is on a disconnected remote
- fix(web): allow new threads when unsettled env is offline #7195: earlier fix was web-only
Activity
juliusmarminge commentedon Oct 8, 2026
Note
Grok responding on behalf of Julius.
Thanks for the clear report. I traced this through the mobile code on
main(12069ee). I haven't reproduced it on a device, so treat the details below as a reading of the code.What seems to happen
The New Task flow doesn't appear to check whether a machine is connected when it picks which copy of a project to open. The default is just "first in list order":
apps/mobile/src/features/threads/new-task-flow-provider.tsx:284-291: with no machine chosen yet,selectedEnvironmentIdfalls back toprojects[0]?.environmentId, the first environment that has any project.apps/mobile/src/features/threads/new-task-flow-provider.tsx:269-282: the project rows are built withbuildHomeProjectScopesand no preferred environment, so each grouped row'srepresentativeismembers[0](packages/client-runtime/src/state/projectGrouping.ts:308-313).apps/mobile/src/features/threads/new-task-project-selection.ts:12-20: tapping a row (NewTaskRouteScreen.tsx:451-454,:467/:490) opens the copy onselectedEnvironmentIdif this project has one, and otherwise therepresentative.packages/client-runtime/src/state/projectEntities.ts:72-95→state/connections.ts:33-41). Disconnected environments that are still enabled stay in it, along with their cached projects.So if the offline machine comes earlier in the catalog, its copy would likely win each time. "Often" rather than "always" probably depends on whether the offline machine's cached project list has loaded. That part is a guess.
The "No project" row on the same screen already seems to do what you're asking for. It appears to only consider connected environments and prefer the selected one (
NewTaskRouteScreen.tsx:181-196). Project rows don't get that treatment.Why it matters more on mobile
On the draft screen, a disconnected target doesn't fail. The button turns into Queue task (
apps/mobile/src/features/threads/NewTaskDraftScreen.tsx:219-223,:316,:1827-1831), and the task waits in the outbox until that machine comes back. Queueing for an offline machine is clearly intended (see the comment at:239-241). Defaulting to that machine when a connected copy exists doesn't look deliberate. I found no last-used or "prefer offline" rule. The flow provider is mounted per New Task sheet (apps/mobile/src/Stack.tsx:899-911), so I don't think a previous choice carries over between sheets.Web/desktop today
There's no shared "prefer a connected copy" helper the mobile app is missing. The web "New thread in…" picker (
apps/web/src/sidebarProjectGrouping.ts:136-167, used fromcomponents/CommandPalette.tsx:964-981) chooses the current thread's project, then the primary environment's copy, then the first member. It doesn't check connection state either. On desktop the primary environment is the local machine, which is always connected, so this rarely shows up there. The web-side attempts to prefer a reachable copy (#7195, #12731, #12912, #13015) were closed unmerged, and #10548 / #12093 are still open. #14490 only hid disconnected environments in Add Project.Possible fix (not verified)
useRemoteConnectionStatus().connectedEnvironmentsis already used in both files. Despite its name, it lists every workspace environment along with itsconnectionState. Using it, the change could be:getProjectScopeSelectionTarget, if exactly one of the row'sscope.projectsis on a connected environment, pick that copy. Otherwise keep today's order, as you suggested.selectedEnvironmentIdfallback in the provider prefer the first connected environment that has projects.Open PR #16832 shows each machine's copy as a separate row with its machine name. That would make the choice visible, but on its own it doesn't change the default.
fix(mobile): picking a project on two machines starts on the connecte…