[Bug]: Android store app disconnects immediately after server.getConfig — RPC protocol skew with all installable server builds

[coreldh]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Closest match is #4671 (closed), which reported the same symptom for a nightly desktop + older Android app. This is the same failure mode, but now it happens with the public Play Store app against released stable 0.0.31, i.e. the default path a new user takes.

Area

apps/server

(The WS/RPC boundary is in the server; the mismatched side is most likely the published mobile binary. See analysis.)

Steps to reproduce

1. macOS, T3 Code desktop 0.0.31 running. Its embedded server listens on *:3773 (all interfaces).
2. Install the T3 Code Android app from the Play Store (build available 2026-07-29).
3. Put the phone on the same Wi-Fi as the Mac.
4. Mint a pairing token on the Mac:
   t3 auth pairing create --ttl 45m --base-url http://<LAN-IP>:3773
5. In the app: Add Environment → HOST http://<LAN-IP>:3773, plus the pairing code.

Expected behavior

The environment connects and stays connected.

If the client's RPC protocol version is not supported by the server, the handshake should fail with an explicit, actionable error (e.g. "client too old, update the app") instead of closing the socket silently and retrying forever.

Actual behavior

The environment is added successfully and displays the correct label pulled from /.well-known/t3/environment — then immediately enters:

Failed to connect. Reconnecting… Reason: <label> connection failed unexpectedly

…and retries indefinitely.

What actually happens on the wire, per server traces:

Stage	Result
GET /.well-known/t3/environment	✅ 200
POST /oauth/token (token exchange)	✅ 200, bearer session created
POST /api/auth/websocket-ticket	✅ 200
GET /ws upgrade + authenticateWebSocketUpgrade	✅ Success
SessionStore.markConnected	✅ Success
ws.rpc.server.getConfig	✅ Success (~40 ms)
Socket survival after that first RPC	❌ closes 75–178 ms after upgrade

Exactly one RPC is ever dispatched (server.getConfig). It succeeds. Then the socket dies. There is no server-side error in the trace — the only failures are benign CommandResolutionErrors from externalLauncher.resolveAvailableEditors probing editors that aren't installed.

Control test: a plain Node ws client from the same LAN, using a ticket issued the same way and mimicking the app's headers (Origin, User-Agent: okhttp/4.9.2, permessage-deflate), upgrades with 101 and holds the socket open indefinitely (verified 8 s, closed by me). So the server's upgrade path, deflate negotiation and auth are all healthy; the failure is specific to the app's RPC conversation.

Note for triagers: /ws spans record http.response.status_code: 204. That is not a symptom — my healthy 8-second control connection also logged 204 (it's the placeholder response for an upgraded socket). The only distinguishing signal is span duration.

Analysis: likely Effect RPC protocol skew

Per @juliusmarminge in #4671, #4643 ("Upgrade Effect and Alchemy betas", merged 2026-07-27T14:21:03Z) contained a breaking change in Effect's RPC protocol, and both sides must be updated together.

I pinned the exact publish boundary on npm:

Version	Published	effect
0.0.29-nightly.20260727.919	2026-07-27T13:25:55Z	4.0.0-beta.78
0.0.29-nightly.20260727.920	2026-07-27T16:10:37Z	4.0.0-beta.102

Every server a user can currently install is on the new side of that break:

• t3@0.0.31 (latest, published 2026-07-29T20:53Z) → effect 4.0.0-beta.102
• t3@nightly = 0.0.32-nightly.20260729.951 → effect 4.0.0-beta.102
• T3 Code desktop (Alpha) 0.0.31 → bundle strings reference 4.0.0-beta.102 (185×), plus a few 4.0.0-beta.103 (8×)

Since there is no installable server on the old side and no newer one to move to, the remaining suspect is the published mobile binary being compiled before #4643 — which would make this #4671 with the roles reversed, and would explain a connection that authenticates, serves one RPC, then drops.

I want to be explicit that I could not verify the app's bundled effect version — that part is inference, not measurement. Everything in the tables above is measured. Happy to run anything specific if it helps confirm.

Impact

Blocks work completely — the mobile app cannot connect to any currently installable server build.

Version or commit

• Server: t3@0.0.31, and T3 Code desktop (Alpha) 0.0.31 (the build actually serving, on *:3773)
• Android app: Play Store build as of 2026-07-29
• I did not runtime-test 0.0.32-nightly.20260729.951; I only confirmed it declares the same effect 4.0.0-beta.102.

Environment

macOS (Darwin 25.5.0, arm64) · T3 Code (Alpha) 0.0.31 embedded server on *:3773 · CLI t3 0.0.31 on Node 22.22.3 · Android client okhttp/4.9.2 · direct LAN pairing, no relay involved.

Logs or stack traces

# phone's retry loop — every HTTP step succeeds (server.trace.ndjson)
18:51:27  GET   /.well-known/t3/environment   -> 200 Success
18:51:27  POST  /oauth/token                  -> 200 Success
18:51:27  POST  /api/auth/websocket-ticket    -> 200 Success
18:51:28  GET   /.well-known/t3/environment   -> 200 Success
18:51:28  POST  /api/auth/websocket-ticket    -> 200 Success
... repeats with backoff indefinitely ...

# the /ws upgrade itself — well-formed request, auth OK, socket dies anyway
name: http.server GET
attributes:
  http.route: /ws
  http.request.header.upgrade: websocket
  http.request.header.connection: Upgrade
  http.request.header.sec-websocket-version: "13"
  http.request.header.sec-websocket-extensions: permessage-deflate
  http.request.header.origin: http://<LAN-IP>:3773
  user_agent.original: okhttp/4.9.2
  http.response.status_code: 204
durationMs: 99.647791
exit: Success

# child spans of that same trace: one RPC, succeeds, then the socket closes
EnvironmentAuth.authenticateWebSocketUpgrade   Success
SessionStore.verifyWebSocketToken              Success
SessionStore.markConnected                     Success
ws.rpc.server.getConfig                        Success   (40.4 ms)
# (the remaining 292 spans are shell.isExecutableFile from editor discovery)

# control: Node `ws` client, same LAN, same headers, same ticket flow
+18ms   UPGRADE http 101  ext="permessage-deflate"
+20ms   OPEN
+8006ms -- STILL OPEN after 8s: socket HEALTHY --

Workaround

Use the web client served by the same server from the phone's browser instead of the native app:

http://<LAN-IP>:3773/pair#token=<pairing-token>

Because that client ships with the server, its RPC protocol matches by construction. It works fine on Android Chrome and can be added to the home screen. This is a usable stopgap for anyone arriving from the launch announcement and hitting this.

[sudosapient]

Additional reproduction (self-hosted Linux server + Tailscale)

Confirming the same failure mode with a slightly different topology than the OP:

Server

• Linux host, t3@0.0.31 as a user systemd service (npx t3@0.0.31 service install)
• Bound to Tailscale IP only: http://100.x.x.x:3773 / MagicDNS http://<host>.ts.net:3773
• No T3 Connect / relay; pure Tailnet HTTP

Clients

Client	Result
Android Play Store app (okhttp/4.9.2)	❌ connect → getConfig OK → socket drop → infinite reconnect (Failed to connect… connection failed unexpectedly)
Desktop Alpha 0.0.28	❌ same reconnect loop against 0.0.31 server
Mobile Chrome (same phone) loading server web UI	✅ stable
Desktop Chrome / browser pair URL	✅ stable

Server-side sequence (matches OP)

1. GET /.well-known/t3/environment → 200
2. pairing / token exchange → 200, session created (client_device_type=mobile, UA okhttp/4.9.2)
3. POST /api/auth/websocket-ticket → 200
4. GET /ws upgrade + authenticateWebSocketUpgrade → Success
5. SessionStore.markConnected → Success
6. ws.rpc.server.getConfig → Success (~50–80 ms)
7. SessionStore.markDisconnected immediately after → client retries forever

No server error on the drop. Control Node WS client to the same endpoint holds the socket open.

Workaround that works for us: open the server URL / pair link in Android Chrome (or home-screen PWA). Because that client is served by the server, RPC versions match.

Happy to pull any extra traces if useful. Thanks for the clear write-up in the OP — Effect RPC skew (#4643) lines up with what we see.

[jssblck]

Additional reproduction: iOS app, and it also fails through the T3 Connect managed relay on stable 0.0.31

Same failure mode as the OP, with two details that extend the reported scope:

1. The client here is the iOS app (T3Code/18 CFNetwork/3860.600.12 Darwin/25.5.0), not Android/okhttp.
2. It reproduces over the T3 Connect managed relay against stable 0.0.31. This issue states the relay was not involved, and [Bug]: Mobile cannot connect to online relays after updating to 0.0.32-nightly.20260730.958 #5031 reports relay breakage only after updating to 0.0.32-nightly.20260730.958. Here the relay fails on plain stable 0.0.31.

Both transports were exercised back to back against the same running server process, minutes apart. The signature is identical.

Setup

• Host: macOS Darwin 25.5.0 arm64
• Server: T3 Code Desktop (Alpha) 0.0.31, embedded server on 0.0.0.0:3773
• Client: iOS app, T3Code/18 CFNetwork/3860.600.12 Darwin/25.5.0
• Transport A: T3 Connect managed relay (https://prod-<redacted>.t3coderelay.com), cloudflared 2026.5.2
• Transport B: Tailscale Serve HTTPS (https://<mac>.<tailnet>.ts.net → http://127.0.0.1:3773)

Transport A: T3 Connect relay (22:30:32 – 22:31:34 UTC)

22:30:32.239   14.1ms  Success  http.server POST  200  /api/auth/websocket-ticket   UA=T3Code/18 CFNetwork/3860.600.12
22:30:32.428  150.7ms  Success  http.server GET   204  /ws   ORIGIN=https://prod-<redacted>.t3coderelay.com
22:30:32.428    0.9ms  Success  EnvironmentAuth.authenticateWebSocketUpgrade
22:30:32.429    0.7ms  Success  SessionStore.verifyWebSocketToken
22:30:32.430    1.5ms  Success  SessionStore.markConnected
22:30:32.467   47.1ms  Success  ws.rpc.server.getConfig          <-- the only RPC ever dispatched
22:30:32.578    0.4ms  Success  SessionStore.markDisconnected

Seven consecutive cycles, all identical. Socket lifetime from markConnected to markDisconnected:

Time (UTC)	/ws span	getConfig	Socket lifetime
22:30:32	150.7 ms	47.1 ms ✅	148 ms
22:30:40	163.4 ms	51.5 ms ✅	161 ms
22:30:57	148.3 ms	34.5 ms ✅	147 ms
22:31:13	173.0 ms	58.3 ms ✅	169 ms
22:31:30	156.9 ms	49.2 ms ✅	156 ms
22:31:32	152.9 ms	54.4 ms ✅	150 ms
22:31:34	180.9 ms	54.1 ms ✅	177 ms

Relink was attempted mid-run and made no difference: POST /api/t3-connect/health → 200, POST /api/t3-connect/mint-credential → 200, GET /.well-known/t3/environment → 200, POST /oauth/token → 200, then straight back into the same loop.

Transport B: Tailscale Serve HTTPS (22:32:20 – 22:35:41 UTC)

Re-paired the phone with a fresh pairing token and switched to Tailscale Serve. Identical outcome.

22:32:20.694    1.4ms  Success  http.server GET   200  /.well-known/t3/environment   UA=T3Code/18 CFNetwork/3860.600.12
22:32:20.721    5.0ms  Success  http.server POST  200  /oauth/token
22:32:20.803    2.8ms  Success  http.server POST  200  /api/auth/websocket-ticket
22:32:20.866  107.6ms  Success  http.server GET   204  /ws   ORIGIN=https://<mac>.<tailnet>.ts.net
22:32:20.866    1.2ms  Success  EnvironmentAuth.authenticateWebSocketUpgrade
22:32:20.866    1.0ms  Success  SessionStore.verifyWebSocketToken
22:32:20.870    1.9ms  Success  SessionStore.markConnected
22:32:20.879   50.1ms  Success  ws.rpc.server.getConfig          <-- again, the only RPC
22:32:20.973    0.3ms  Success  SessionStore.markDisconnected

Time (UTC)	/ws span	getConfig	Socket lifetime
22:32:20	107.6 ms	50.1 ms ✅	103 ms
22:32:22	131.5 ms	66.3 ms ✅	127 ms
22:32:24	105.5 ms	45.9 ms ✅	103 ms
22:32:28	109.6 ms	50.0 ms ✅	108 ms
22:32:36	104.1 ms	47.7 ms ✅	101 ms
22:32:48	105.2 ms	50.4 ms ✅	101 ms
22:35:41	95.8 ms	36.2 ms ✅	94 ms

The upgrade request itself is well formed on this path (connection: Upgrade, upgrade: websocket, sec-websocket-version: 13, origin: https://<mac>.<tailnet>.ts.net, x-forwarded-proto: https), and Tailscale Serve's tailscale-user-* identity headers are present and harmless.

Confirming the OP's triage note: /ws logs http.response.status_code: 204 on both transports. It is not a symptom.

Controls

Transport health was verified independently on both paths, so neither bridge is the cause:

• cloudflared metrics: cloudflared_tunnel_ha_connections 4, /ready → {"status":200,"readyConnections":4}, four distinct edge locations, 33 requests served. TCP and UDP 7844 to the Cloudflare edge both reachable.
• tailscale serve status maps / → http://127.0.0.1:3773 correctly. GET /.well-known/t3/environment over the Serve URL returns 200 with the correct descriptor.
• A curl WebSocket upgrade to /ws over the Serve URL with a deliberately invalid ticket reaches the handler and returns a clean 401 EnvironmentAuthInvalidError, so the upgrade path is intact end to end from an external client.
• Server-side session records show the phone paired successfully: client_device_type=mobile, client_os=iOS, last_connected_at set, revoked_at null. Pairing, OAuth and ticket issuance are all healthy.

Strongest in-situ control: while the phone was looping, the desktop client on the same machine held its own WebSocket to the same server process and did real work (ws.rpc.vcs.listRefs, ws.rpc.filesystem.browse, ws.rpc.orchestration.dispatchCommand, ws.rpc.assets.createUrl at 22:32:33 through 22:32:44). One client sustains the RPC session; the other drops after exactly one call.

What this narrows

The ws.rpc.server.probe follow-up call never appears in any trace, on either transport. Per EnvironmentSupervisor, the client chains probe off the decoded initialConfig result, and this server advertises connectionProbe: true. The socket dying between a server-side-successful getConfig and an absent probe is consistent with the client failing to decode the server.getConfig response rather than rejecting its contents, which matches the RPC protocol skew analysis in the OP.

I could not measure the iOS app's bundled effect version, so that last step is inference, not measurement. Everything above is measured from server.trace.ndjson.

Happy to run anything specific, including a Node ws control over either transport if someone can point me at the cleanest way to mint a ticket outside the app.

Workaround confirmed on iOS

The OP's workaround works here. Serving the web client from the same server over the existing Tailscale Serve HTTPS origin gives a stable connection on the same phone that the native app cannot hold:

https://<mac>.<tailnet>.ts.net/pair#token=<pairing-code>

/pair returns 200 and manifest.webmanifest returns 200 over that origin, so Add to Home Screen produces a working standalone PWA on iOS.