fix(mobile): bare t3code:// links no longer reset navigation to Home

[SunkenInTime]

Fixes #11950

What Changed

The React Navigation linking.filter in apps/mobile/src/App.tsx is extracted into shouldHandleAppLink(url) in apps/mobile/src/lib/appLinking.ts. In addition to the existing Expo dev-client / expo-sharing exclusions it now returns false for scheme-only URLs:

!/^t3code(-dev|-preview)?:\/*$/.test(url)

Path-bearing links (t3code://threads/..., t3code://pair?..., t3code-dev://settings/usage?...) are unchanged. Unit tests cover the bare schemes (t3code://, t3code:///, -dev, -preview), the lifecycle URLs, and the path-bearing cases.

Why

iOS returns to the app with a bare t3code:// URL (e.g. after the dictation keyboard / sibling app hands control back). React Navigation matched that against the Home screen, whose linking path is "", and reset the stack — dropping whichever thread the user had open. A scheme-only URL carries no destination, so it should only wake the app, never navigate.

Reproduce

1. Build the iOS dev client, pair it to a local server, open any thread.
2. From Safari (or xcrun simctl openurl booted "t3code://") open the bare t3code:// URL.
3. Before: the app comes to the foreground on Home and the thread is gone from the stack. After: the app foregrounds on the thread it was already showing.

UI Changes

Verified on an iPhone 17 Pro simulator (iOS 26.5, t3code-dev dev client, disposable local T3 server with a seeded thread). Same steps each time: open the thread, then xcrun simctl openurl <device> t3code-dev://.

Before (main @ 7a368fe) — bare link resets to Home, thread gone	After — thread stays open	After — t3code-dev://threads/<env>/<thread> still navigates

Also covered by unit tests (vp test run apps/mobile/src/lib/appLinking.test.ts) plus mobile typecheck and lint.

Checklist

• This PR is small and focused
• I explained what changed and why
• I included before/after screenshots for any UI changes
• I included a video for animation/interaction changes

Written by Claude (Devin harness).

Summary by CodeRabbit

• Bug Fixes

  • Improved mobile app-link handling by ignoring development-client and sharing lifecycle URLs.
  • Prevented scheme-only links from triggering navigation.
  • Continued supporting valid links to threads, pairing, settings, and other in-app destinations.

• Tests

  • Added coverage for ignored lifecycle and scheme-only links, along with supported navigation links.

[macroscopeapp]

Approvability

Verdict: Approved at 5df34ca

Macroscope's review found this PR approvable — This is a small, self-contained mobile deep-link bug fix that ignores bare app-scheme wakeups while preserving path-bearing links and existing lifecycle filtering. Focused regression tests cover the new predicate, with no product-default or static-analysis configuration changes.

^{You can add or adjust custom eligibility rules. Learn more.}

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: 1eaca444-2431-4a61-acac-6af8c505b129

📥 Commits

Reviewing files that changed from the base of the PR and between 935c55b and 5df34ca.

📒 Files selected for processing (3)

• apps/mobile/src/App.tsx
• apps/mobile/src/lib/appLinking.test.ts
• apps/mobile/src/lib/appLinking.ts

Included review availability: Your plan provides up to 10 included reviews per hour; 8 remain after this review.

---

📝 Walkthrough

Walkthrough

The mobile app now uses a shared shouldHandleAppLink predicate. The predicate ignores scheme-only and Expo lifecycle URLs while accepting path-bearing links. Tests cover these cases.

Changes

App-link filtering

Layer / File(s)	Summary
App-link predicate and coverage apps/mobile/src/lib/appLinking.ts, apps/mobile/src/lib/appLinking.test.ts	Adds shouldHandleAppLink and tests its handling of scheme-only, Expo lifecycle, path-bearing, and query-bearing URLs.
App integration apps/mobile/src/App.tsx	Uses shouldHandleAppLink as the app-link filter before navigation.

Priority: ⬇️ Low

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix · Severity of issue fixed: Low

Merge Risk: ⚪ Minimal · up to 5df34

The link filter rejects the specified bare and lifecycle URLs while retaining tested path-bearing links. No confirmed merge-blocking risk remains.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main fix: preventing bare t3code:// links from resetting mobile navigation to Home.
Description check	✅ Passed	The description is complete and relevant. It explains what changed, why it changed, how to reproduce the issue, the expected behavior, validation results, and UI evidence. The checklist is largely com…
Linked Issues check	✅ Passed	The changes satisfy the coding requirements in issue #11950. App.tsx uses shouldHandleAppLink as the React Navigation filter. The predicate rejects t3code://, t3code:///, t3code-dev://, and …
Out of Scope Changes check	✅ Passed	The changes stay within issue #11950. They extract the app-link filter, add focused unit tests, and connect the filter to App.tsx. These changes directly support the bare-scheme navigation fix and p…
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 3 files.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands.}