[Bug]: incompatible environments hide app/server update guidance

[rogu3bear]

Problem

An incompatible environment is presented as only “Client not supported”, losing the compatibility error that explains whether the mobile app or host needs an update.

This is a diagnostic-loss bug, separate from the expected V1/V2 incompatibility documented in #14871. It does not request interoperability between those protocols.

User-reported reproduction

1. Install T3 Code on an iPhone from the App Store and sign in with the same GitHub account as the desktop.
2. Run the preview desktop. The locally inspected host was 0.0.46-preview.20261002.2598, orchestration protocol 2.
3. On the same local network, open mobile Settings → Environments. The host appears under T3 Connect but cannot be enabled.
4. Scan the host's connection QR code. The user reports that scanning succeeds and the incompatibility appears after pressing Connect.

The user reports an empty “No environments connected” screen while task notifications and Dynamic Island activity still arrive. The exact iPhone version/build is unknown; its installation channel was confirmed as App Store. These physical-phone observations have not been independently reproduced.

Source reproduction

orchestrationProtocolCompatibilityError already returns directional recovery text, but connectionStatusText discarded it for the unsupported phase. Mobile availableCloudEnvironmentPresentation separately hardcoded the same generic status.

Before: unsupported connections with actionable errors show only “Client not supported”.

Expected: retain the negotiated compatibility message, including “Update your app” for a newer server and “Update T3 Code on [host]” for an older server. Keep incompatible connections disabled and retain the generic fallback when no error detail exists.

Four focused regression cases failed on this lost-detail behavior before the repair. The fix and affected compatibility/onboarding/resolver cases now pass: 52 tests across seven files, plus targeted lint, formatting and typechecks for client-runtime, mobile and web.

Recovery and scope

The user selected V2 TestFlight with the current preview desktop, following #14871. App Store V1 and preview V2 cannot connect merely because GitHub authentication and network discovery succeed. The proposed repair preserves the existing compatibility checks and makes their recovery guidance visible. Related reverse-direction report: #14901.

[juliusmarminge]

Note

Grok responding on behalf of Julius.

Triage

Thanks @rogu3bear for the careful report, including the exact versions and the functions involved. That made this straightforward to trace.

What I found

The behavior you describe matches the code, and it's separate from the V1/V2 split tracked in #14871.

orchestrationProtocolCompatibilityError already returns the directional sentence: "Update your app…" when the server is newer, and "Update T3 Code on {host}…" when it's older. On mobile, the Environments list never shows it. availableCloudEnvironmentPresentation stores that sentence on connectionError but sets statusText to "Client not supported", and the row renders statusText. Saved rows go through connectionStatusText, which ignores connection.error in the unsupported phase, and expanding the row doesn't reveal the sentence either. The pairing alert is the one place where the compatibility error does show.

Web keeps the short subtitle on purpose (#12026) and puts the full sentence in a tooltip, and Settings → Environments also offers Update when the host can update itself (#15002). Mobile has no tooltip and no Update action, so "Client not supported" is the only guidance on this path.

For context, the refused connection itself comes from the protocol mismatch: the App Store build speaks protocol 1 and can't connect to a protocol 2 preview host, and the V2 iOS app is the TestFlight linked from #14871. Keeping the switch disabled matches that.

Current tests still expect the generic label: packages/client-runtime/src/connection/presentation.test.ts and apps/mobile/src/features/cloud/cloudEnvironmentPresentation.test.ts.

Likely fix area

• One option is showing the existing compatibility detail on the mobile row, falling back to "Client not supported" when there's no detail.
• Another is exposing the detail on expand, or adding a mobile equivalent of the web tooltip or Update action.
• Either way, the web subtitle and the no-reconnect-across-protocols behavior could stay as they are, and the two tests above would move with the change.

A maintainer will decide on the fix direction.

[christhomas]

yes, I'm getting this problem as well, I installed t3 code onto an iphone 16 yesterday and ran straight into this problem, the app says it was updated 2 days ago, but apparently it isn't updated with the latest protocol or client to talk with the servers, maybe this sort of thing, keeping clients upgraded, should be an automated process where it uses a latest version of a client library and when you update the main protocol, the other libraries are updating themselves and rebuilding the protocol libraries to include into mobile apps and deploying them to app stores without needing to manually upgrade them?

Whilst it's great to show the real error and the real problem instead of just a generic "Client not supported" text, which is opaque and mysterious. But is there any ETA to actually fixing the mobile app as well so it doesn't have this problem in the first place?

[rogu3bear]

¯|(ツ)/¯

[christhomas]

I don't remember how this came about, but I was prompted by t3code to install the beta version of the app and this is what I needed to do to get it working with my iphone again. I installed testflight, scanned the qr code, it installed it again as the beta version and thats what made it work. I think its not very clear, or it's easy to gloss over, that if you're using the nightlies, like most of us on github probably are. We need to use the testflight version (I don't know what the android version of that is).

Then, all my threads came back and everything was working just like it was before.

I was using the normal app store version until recently without any problems. But I wonder if there was a breaking change in the app (orchestrator v2?) and that needed to be in the default app store version and it wasn't, its perhaps only available in the beta version, hence the requirement for testflight to install it that way

See if that helps your situation