[Bug]: iOS: opening the bare t3code:// URL navigates to Home and drops the current thread

[Pivii]

Before submitting

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

Area

apps/mobile

Steps to reproduce

1. Open a thread in T3 Code on iOS and start typing a draft.
2. Send the app to the background.
3. In Safari, open t3code:// and confirm "Open in T3 Code".

Expected behavior

T3 Code comes back to the foreground on the same thread. That is what a bare URL scheme does for Claude (claude://), ChatGPT, GitHub or Slack.

Actual behavior

T3 Code navigates to Home. t3code:/// behaves the same.

Impact

Minor bug or occasional failure

Voice dictation keyboards on iOS record in their own app, then send the user back to the app they were typing in by opening that app's URL. In T3 Code the user lands on Home after every dictated prompt and has to find the thread again. For context, Wispr Flow does not return to T3 Code at all, and Dictus, which I build, returns to Home.

Cause, from reading the source: apps/mobile/src/App.tsx registers t3code:// as a linking prefix. An empty path resolves to the route declared with linking: "", which is Home.

Suggested fix: extend the existing filter. This is the same idea as the expo-sharing exclusion already there: a URL that only wakes the app.

filter: (url: string) =>
  !url.includes("expo-development-client") &&
  !url.includes("://expo-sharing") &&
  !/^t3code(-dev|-preview)?:\/*$/.test(url),

iOS still brings the app to the foreground; only the navigation is skipped.

Live Activities are unaffected. apps/mobile/src/widgets/AgentActivity.tsx builds t3code://<path> and sets no URL when there is no path. Checked on device: with several Live Activities pointing at different threads, each one still opens its own thread. Not checked: the link used by the subscription usage widget.

Version or commit

T3 Code 1.1.0 (App Store), source read at 3efdcc529

Environment

iPhone 15 Pro Max, iOS 27.0

Logs or stack traces

No response

Screenshots, recordings, or supporting files

Screen recording to follow in a comment.

Workaround

None.

[Pivii]

Screen recording: t3code:// opened from Safari lands on Home

trim.6640E97D-18E1-402C-A955-D5EC65F24950.MOV

[juliusmarminge]

Triage

Confirmed as a mobile linking bug, not a duplicate of the desktop deep-link work.

Opening a thread, backgrounding the app, then opening t3code:// (or t3code:///) from Safari brings T3 Code forward and navigates to Home, dropping the current thread. That matches the recording and the App Store 1.1.0 / 3efdcc529 source.

Cause

apps/mobile/src/App.tsx registers t3code://, t3code-dev://, and t3code-preview:// as React Navigation prefixes. The existing filter only skips Expo dev-client and expo-sharing wake URLs. A scheme-only URL is treated as a real deep link.

Root Home in apps/mobile/src/Stack.tsx is linking: "". After the prefix is stripped, t3code:// / t3code:/// is an empty path, so navigation resets to Home (config.initialRouteName: "Home"). iOS still foregrounds the app either way; only the navigation should be skipped. That is the same pattern as the expo-sharing exclusion from #4021.

Path-bearing links are a different code path and should stay as they are:

• Live Activities: t3code://threads/<environmentId>/<threadId>
• Subscription usage widget: …/settings/usage?tab=limits (not a bare scheme)
• Pairing QR: t3code://pair?pairingUrl=…

Not a duplicate of #9745

#9745 / #8246 are desktop: path-bearing t3code://threads/… links are ignored. This issue is iOS/mobile: the bare scheme is consumed and incorrectly mapped to Home. Same URL scheme, different surface and opposite symptom.

Suggested fix

Extend the existing filter so a URL that is only the app scheme (any number of slashes, including t3code-dev / t3code-preview) is ignored for navigation:

filter: (url: string) =>
  !url.includes("expo-development-client") &&
  !url.includes("://expo-sharing") &&
  !/^t3code(-dev|-preview)?:\/*$/.test(url),

Cold start via t3code:// still lands on Home via initialRouteName. The same linking config exists on Android; a bare scheme would reset to Home there too, but the dictation-keyboard loop is iOS-specific.

Please extract the predicate and add unit tests for bare vs path-bearing vs the two existing Expo exclusions. No change needed to Home’s empty path, Live Activity URLs, or the usage widget.

Next step

Small, well-scoped change in apps/mobile/src/App.tsx. Ready to implement.

[Pivii]

Thanks for the quick turnaround on #12002 — the extracted shouldHandleAppLink with a test is nicer than what I suggested.

I tried to confirm the fix on device and can't yet: the App Store build is still 1.1.0, and from the mobile-eas-production run on 0ec2b08a9 the OTA went out on the production channel at runtime version 969ad8f4, which matches the 1.2.0 build train rather than the 1.1.0 binary I'm running.

Three questions, happy to be pointed at a doc instead of answered directly:

1. Beta access — is there a TestFlight group I can join to verify this on device? I'm the reporter and this is a one-minute repro, so I can close the loop for you.
2. Mobile release cadence — I understand releasing 1.2.0 to the App Store is a manual step. Is there a rough cadence for mobile releases, or does a version ship when it's ready?
3. Contributing to the iOS app — I read CONTRIBUTING.md and understand you're not actively taking contributions. I build a dictation app myself and care about this corner of the product, so if small, focused mobile bug fixes are useful, I'd be glad to pick some up. Is there a label or a set of issues you'd rather see handled, or should I keep to reporting with a suggested patch like this one?

No rush on any of it.