Repository navigation
Mobile environment connection and thread sync take 20–30 seconds on LAN #26667
Description
What happened
On T3 Code mobile 2.1.0, connecting to my T3 Code environment and synchronizing threads is very slow on an iPhone 17 Pro and a 12.9-inch iPad Pro. On the local network, the app shows a reconnecting-to-Mac status for about 20–30 seconds, then "Syncing threads" for another 20–30 seconds. It used to be almost instantaneous. The delay over cellular data has not been timed.
Diagnosis
The host is the T3 Code Nightly desktop app on macOS. Its local environment endpoint reports server version 0.1.4-nightly.20261028.3841. In the matching server release source, the mobile client uses the shared client runtime to connect, load the thread-list snapshot, and subscribe to thread updates. The retained server and desktop traces contain desktop client activity, but no iPhone or iPad client spans. They do not show where the reported mobile delay occurs. The host database has about 3,500 threads across 12 projects, including one archived thread. I found no matching existing issue or newer release with a known fix. Root cause is unknown.
Steps to reproduce
- Run T3 Code Nightly 0.1.4-nightly.20261028.3841 on macOS.
- Open T3 Code mobile 2.1.0 on an iPhone 17 Pro or 12.9-inch iPad Pro.
- Connect to the macOS environment over the local network.
- Observe a reconnecting-to-Mac status for about 20–30 seconds, followed by "Syncing threads" for another 20–30 seconds. This used to be almost instantaneous.
- Connect over cellular data and observe the same reported slowness. Its duration has not been timed.
Version
macOS server: 0.1.4-nightly.20261028.3841 (9e09926)
iPhone/iPad app: 2.1.0
iPhone: iPhone 17 Pro, iOS 27.0.1.
iPad: 12.9-inch iPad Pro, latest iPadOS (exact version not provided).
Environment
Host: Mac mini, macOS 27.0.0, arm64, T3 Code Nightly desktop app.
Mobile app installation channel: unknown.
Evidence
-
The local environment endpoint reports serverVersion 0.1.4-nightly.20261028.3841.
-
Retained server and desktop traces show desktop client activity, with no iPhone or iPad client spans.
-
The host currently has about 3,500 non-deleted threads across 12 projects, including one archived thread.
-
User reports that LAN connection shows a reconnecting-to-Mac status for 20–30 seconds, followed by "Syncing threads" for another 20–30 seconds. The app used to be almost instantaneous.
-
In a Charles Proxy capture on 2026-10-28 (UTC−05:00), these requests returned HTTP 200 but spent nearly all their time waiting for the response:
Start time Request Total duration Wait before response 18:32:12.870 GET /api/orchestration/shell22.126 s 22.048 s 18:32:12.879 GET /api/auth/session1.274 s 1.271 s 18:33:56.894 GET /api/orchestration/shell18.013 s 17.604 s 18:33:56.916 GET /api/auth/session16.450 s 16.447 s -
Other
/api/auth/sessionrequests in the same capture took 23 ms and 28 ms. Environment discovery requests took 2–17 ms. The slow/api/auth/sessionrequests started within 22 ms of slow shell requests. This timing may point to shared processing or contention, but the HAR does not establish causation. -
Two
POST /mcprequests invokingdelegate_tasktook 20.059 s and 1.335 s. These are listed separately because they may include expected delegation work. -
Cellular-data slowness is reported, but its duration has not been timed.
-
No matching issue or newer release with a known fix was found.
Related issues
No matching issue found. Existing reports about mobile thread scrolling or stale pin state describe different symptoms.
Fix applied or workaround
None.
Filed by
GPT-6 Codex via T3 triage.
Activity
[-]Mobile environment connection and thread sync are slow on Wi-Fi and cellular[/-][+]Mobile environment connection and thread sync take 20–30 seconds on LAN[/+]juliusmarminge commentedon Oct 28, 2026
I tried to reproduce this on current
main(d464631, three unrelated commits after your server's 9e09926) and could not get a slow connect or sync:So the 20–30 s probably depends on something in your setup that this run didn't have. Could you add:
fdubayteq commentedon Oct 28, 2026
I updated the issue description with the iPhone and iPad details, the two wait states shown in the app, the host thread count, and the Charles Proxy timings. The requests returned HTTP 200; their timing does not establish a cause. The two /mcp delegate_task requests are listed separately.
juliusmarminge commentedon Oct 30, 2026
Thanks for the Charles timings. They pointed at the server. I compared your server build (9e09926) with current
main(c8a606c) on a host the size of yours: 12 projects, 3,500 threads, 14,000 runs and 700k–840k turn items (a 4–5 GBstatev2.sqlite), about 80% of the threads settled. Each server created its own database. I firedGET /api/orchestration/shellwith the options the mobile app sends, together withGET /api/auth/session, the way your capture shows them. "Cold" means after dropping the OS page cache.main/api/orchestration/shell, cold/api/orchestration/shell, warm/api/auth/sessionsent alongside itBoth delays in your capture show up on your build: the slow shell read, and
/api/auth/sessionwaiting behind it. Two changes onmainaddress them:Both first ship in nightly
0.1.6-nightly.20261030.3904. Your 22 s is larger than anything this host produced, so if connecting is still slow on that nightly, please reopen with the size ofstatev2.sqlitein your T3 home'suserdatafolder, and note whether agents were running on the Mac at the time.