You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: iOS Local Network permission sheet leaves pairing stuck until force-quit #5061
I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.
Closest related: #4921 (closed after documenting force-quit as a workaround). This issue is specifically about recovering in-process after the Local Network permission sheet, without requiring a cold start.
Fresh iOS install (or reset Local Network permission for T3 Code).
Enable Network access on the desktop environment and create a pairing link.
On iPhone, add/pair the environment over LAN (http://192.168.x.x:3773).
When iOS shows the Local Network permission prompt, tap Allow.
Observe the environment stay in Failed to connect. Reconnecting… even though permission is granted and the desktop server is reachable.
Force-quit and reopen the iOS app — connection succeeds.
Expected behavior
After the user taps Allow, the in-flight (or immediately subsequent) connection attempt should recover and connect without force-quitting the app.
Actual behavior
The permission sheet briefly moves the app to inactive and back. That resume is emitted as application-active-probe, but during establishment the supervisor consumes and ignores probe wakeups. The attempt that triggered the sheet is usually already doomed, so the client falls into backoff and does not immediately replace the attempt with one that can use the newly granted Local Network access. Force-quit is the only reliable recovery today — bad UX.
Impact
Major degradation or frequent failure for first-time LAN pairing on iOS.
Version or commit
Reproduced against current main-line mobile connection runtime behavior (see waitForEstablishmentInterrupt in packages/client-runtime/src/connection/supervisor.ts and mobile AppState wakeups).
Environment
iOS native app
Desktop / server with Network access enabled
Direct LAN pairing (same Wi-Fi)
Workaround
Force-quit and reopen the iOS app after granting Local Network.
Proposed fix (small / focused)
During establishment, treat application-active wakeups (including probe) as an interrupt that resets the retry ladder.
On mobile, treat AppState inactive as a suspension start so permission sheets are tracked the same way as brief backgrounding.
Happy to open a tightly scoped PR for this once maintainers want it.
This is an automated response from a bot acting on maria's behalf.
This issue has had no activity since 2026-07-31.
Is it still relevant on the current version? If so, your version and OS would help.
Activity
maria-rcks commentedon Oct 9, 2026
Note
This is an automated response from a bot acting on maria's behalf.
This issue has had no activity since 2026-07-31.
Is it still relevant on the current version? If so, your version and OS would help.