claude:// session deep link opens app but not the specific session (Remote Control "local" session)
Summary
get_session("self")'s link field returns a claude:// deep link intended to open a specific session directly. When triggered from a mobile browser context (e.g. a webpage's window.location.href), iOS correctly hands off to the installed Claude app — confirming the app is registered as the handler for the claude:// scheme — but the app opens to its generic home screen instead of the targeted session.
Steps to reproduce
- Have a Claude Code session running locally on a Mac with Remote Control enabled (
set_remote_control,enabled: true) — session ID has alocal_prefix. - Call
get_session("self")and take the returnedlinkfield, shaped likeclaude://claude.ai/epitaxy/<session-id>. - From an iPhone with the Claude app installed and updated to the latest version, trigger that URL from within a web page (e.g.
window.location.href = linkfrom a button tap in Safari/Chrome). - Observe the result.
Expected: The Claude app opens directly to the specified session.
Actual: iOS switches from the browser to the Claude app (confirming OS-level scheme registration works), but the app lands on its default home screen ("Evening, [name]") rather than the session. The user then has to manually navigate (hamburger menu → Code → find the session by title) to reach it.
Notes / hypotheses (unconfirmed — no visibility into app internals)
- This may be specific to
local_-prefixed (Remote-Control-bridged) sessions rather than fully cloud-hosted ones — untested whether the same link format resolves correctly for a cloud session. - The
linkfield's own tool description frames it as intended for "text that leaves this conversation (a PR description, Slack, a file)" — it's possible mobile deep-linking into a specific session was never wired up, rather than being wired up and broken. - No error is shown; the app just silently falls through to home, which made this hard to distinguish from "the link isn't handled at all" until we confirmed the app switch itself was happening.
Environment: iOS (iPhone), Claude app (latest, updated during testing), trigger context: Chrome/Safari mobile browser, Remote Control session hosted on macOS.
3 Comments
Additional environment detail that should have been in the original report:
The triggering page was loaded as an installed PWA (standalone display mode), not a regular browser tab. The web app that generated the
claude://link is configured with a manifest ("display": "standalone") and iOS home-screen meta tags (apple-mobile-web-app-capable), and the user always launches it from its home-screen icon, never from Safari/Chrome directly. Sowindow.location.href = <claude:// link>executed inside a standalone WKWebView context, not a normal in-browser tab. Standalone/home-screen PWAs on iOS have a known history of handlingwindow.open()and custom-URL-scheme handoffs to other apps inconsistently compared to a regular Safari/Chrome tab -- this seems like a plausible contributing factor to the link only partially working (switched to the Claude app, but didn't route to the specific session), separate from whatever is happening inside the Claude app's own routing.Also worth noting: the PWA itself is served over a Tailscale connection (a private MagicDNS HTTPS domain, e.g.
https://<device>.<tailnet>.ts.net/..., backed by a Tailscale-issued/trusted cert) rather than localhost or the public internet. Likely not the root cause, but flagging for completeness in case the origin/serving context matters to how iOS evaluates permission for the scheme handoff.Happy to test variations (e.g. same link from a plain Safari tab instead of the PWA) if that would help narrow this down.
Same symptom from a different entry point: a push notification whose tap target is
https://claude.ai/code/session_…(set by a Home Assistant companion-app notification) opens Safari. Choosing "open in app" then lands on the Claude iOS app's Home screen, not on the session.So tap-to-open from a notification can't reach a specific Remote Control session on iOS by either route (https link or
claude://). Supporting a session-specific deep link in the app would fix both this and the case above.Claude Code 2.1.287, iOS Claude app, session hosted in tmux with Remote Control.
👍