[FEATURE] iOS: start new Claude Code sessions on my paired Mac, with full feature parity

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Today, the only way to start a new Claude Code session is from my Mac — by opening a terminal and running claude. Once a session is running, I can pair it to mobile with /remote-control and steer it from my phone. But if I'm not physically at my Mac, I can't start a new session at all.

That blocks an entire class of workflows. The session needs to run on my actual Mac — with its logged-in browser, its full filesystem, its locally-configured MCPs, and its native desktop apps — because that's where all my work, credentials, and tools live. Nothing in the cloud has access to those, and nothing in the cloud can be made to.

The asymmetry today:

• From my desk: I can start a Claude Code session on my Mac with full local capabilities. ✅
• From my phone: I can steer sessions I already started at my desk. I cannot start a new one. ❌

The ask is to close that asymmetry.

Proposed Solution

Let the iOS app start new Claude Code sessions on the user's paired Mac, with full Claude Code feature parity — equivalent to having run claude from a terminal on that Mac.

The new session should inherit everything a desk-started session would:

• Full filesystem access at a user-specified cwd
• Logged-in local browser
• All locally-configured MCPs (computer-use, claude-in-chrome, scheduled-tasks, custom connectors with host credentials)
• Native computer use against the desktop
• The user's real shell, env, and credentials
• All custom agents, skills, slash commands, hooks, and settings from ~/.claude/
• Support for multiple concurrent sessions, not one-at-a-time

Once started, the session should appear in the iOS app exactly as if it had been launched from the desk and /remote-control-paired — same UI, same controls, same lifecycle.

Why existing issues don't cover this

• #48949 (Persistent always-on Remote Control) — about auto-enabling RC on already-started sessions. Doesn't address starting new sessions from mobile.
• #46460 (Use Dispatch from Claude Desktop) — about cross-workstation routing, different surface.
• #15922 / #25115 (Mobile Companion App) — about push notifications and approve/deny on existing sessions. Steering, not starting.

Spawn ≠ steer. Worth its own thread.

Alternative Solutions

• Start a session at the desk before leaving. Today's workaround. Doesn't work when the user isn't at the desk in the first place.
• SSH from mobile. Functionally possible, lacks the native UX (push notifications, diff approval, mobile-rendered session view).

Priority

High — Significant impact on productivity for any workflow whose value depends on logged-in local state, native desktop apps, computer use against the actual desktop, locally-configured MCPs, or files outside any GitHub repo.

Feature Category

iOS app / Remote Control

Use Case Example

I'm out and want Claude to audit a few of my logged-in browser tabs for outstanding items, summarize what's actionable, and queue follow-ups in my local notes system. This requires my actual Chrome, my actual local files, and my actual MCPs — none of which are accessible to anything except a session running on my Mac.

Today: blocked until I'm home.

With this feature: from the iOS app, start a new Claude Code session on my Mac. It spawns with full local capabilities, and I drive it from my phone.

The same pattern applies to any mobile-initiated workflow touching local notes, screenshots, native desktop apps, logged-in web services, or any MCP that requires host credentials.