[Bug]: iOS Nightly LAN entry does not return after T3 Connect off/on/off cycle#23367

This was generated by AI during triage.

What happened

On an iPhone at home on Wi-Fi, three environments are initially visible. One host is reachable on the home LAN and is also linked through T3 Connect. After a T3 Connect off/on/off sequence, that host's LAN entry no longer returns to the local environment list, although the other two remain.

The reporter explicitly confirmed this was observed in the official T3 Nightly phone client as well, not only a downstream fork. Host/account names and addresses are omitted here.

Steps to reproduce — reporter-observed sequence

Use three environments A/B/C; B is reachable on the home LAN and also available through T3 Connect.

1. With T3 Connect on, all three environments are visible.
2. Turn T3 Connect off: all three remain visible.
3. Turn it back on: B's entry disappears from the LAN/local group; B is the same environment available through T3 Connect.
4. Turn it off again: B does not return to the LAN/local group. A/C remain.

The exact switch/menu path has not yet been captured. In particular, this report does not equate a host exposure toggle, account sign-out, and an individual environment enable switch. Whether B remains in the T3 Connect group after the final step, and its route marked In use, still need recording. The full cycle has not been independently replayed by the investigating agent.

Expected behavior

An independently paired, still reachable LAN route should survive enabling/disabling Connect for the same environment. Deduplicating two routes into one environment row is fine; duplicate rows are not requested. The UI should make clear whether an entry merely moved groups, whether its LAN route remains saved, and which route is active. If the LAN address was learned using Connect credentials rather than independently paired, that different ownership/lifetime should be distinguishable.

Diagnosis / investigation limits

No root cause or persistent route/credential loss is established yet. The observations could involve route ownership, UI grouping, or the meaning of the toggle.

Source checked at published Nightly v0.1.2-nightly.20261021.3499 (b5a226e49c52ecab4ddc2d678a7012d97e651a6a) and current upstream main 002e941fbb2ec01a4f4b02355995117e68452322. The six inspected registry/routes/presentation/mobile grouping/cloud cleanup files have identical Git blob IDs at those two pins and match the investigated fork files.

• Environment grouping uses hasRelayRoute(entry), not the active route. Mobile sections then group that environment under T3 Connect. Moving groups alone does not prove traffic uses the relay or LAN state was deleted.
• Route registration normally merges the new route with existing routes for that environment.
• Route removal preserves independently saved routes, but intentionally removes Connect-learned routes when their parent Connect route is removed.
• Documented behavior says alternate routes share one environment and signing out keeps machines still reachable another way.

Tailscale is installed on the host, but there is no evidence that it caused this behavior. No VPN, network settings, live credentials, saved environments, or host services were changed for this triage.

Evidence / reproduction attempt

Ran the existing registry tests against the unchanged Nightly implementation:

These confirm the simpler paired-LAN/Connect preservation cases. They do not reproduce the reported UI toggle cycle or establish route loss. A useful next regression would cover independently paired LAN -> add same-ID Connect -> learn endpoints -> remove/re-add/remove Connect -> reload catalog, with a separate Connect-learned-LAN control case.

Version / environment

• Observed client: official T3 Nightly on iPhone/iOS; exact mobile version/build and iOS version not yet captured.
• Investigation source baseline: Nightly3499 above; this is not asserted to be the reporter's exact official phone binary version.
• Phone and affected host on the home Wi-Fi/LAN; three environments, one with both LAN and Connect availability.
• Category: possible bug; needs maintainer triage. Not a security report or a confirmed data-loss claim.

Related issues / duplicate search

Searched open and closed issues for Connect/LAN, sign-out, disappearance and toggle behavior.

• #5242 (closed): same backend's Connect listing hidden while a direct entry exists. Related deduplication/discoverability, but this report concerns the later off/on/off round trip and missing local return.
• #17917 (open): saved Connect environments removed after an offline Clerk startup. Related cleanup path; this report has an explicit toggle sequence while at home, with no confirmed offline startup or shared cause.

No exact duplicate identified; these may help maintainers classify the report.

Fix applied or workaround

No fix or destructive workaround attempted. Do not remove/re-pair a healthy environment merely to collect evidence. Needed follow-up: exact toggle path, official client build, whether the remaining Connect row still represents B, and sanitized route lists (including saved versus learned and In use) before/after each step. No tokens or private account data needed.

Filed using the triage skill by gpt-6.1-sol (high reasoning), Codex in T3 Code, from the reporter's observations and bounded source/test research.