[FEATURE] Universal session portability: --remote, /teleport, and remote-control should work across all Claude Code surfaces

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

Claude Code sessions are siloed by surface. A session started in the Claude desktop app cannot be resumed in the CLI, and CLI features like claude --remote, /teleport, and claude remote-control are inaccessible from desktop app sessions. The same limitation applies in reverse — there is no path to pull a desktop app session into a terminal or hand it off to cloud execution.

This means the surface you happened to start in determines what you can do for the entire lifetime of that session. That is artificial and counterproductive friction that undermines the core value prop of Claude Code.

Related narrower issue: #29006 (Remote Control not accessible from desktop app sessions). This request covers the full scope of cross-surface portability.

Proposed Solution

Session state should be shared across all Claude Code surfaces. It should not matter whether a session was started from:

• The Claude desktop app
• The CLI (bash/terminal)
• The VS Code / JetBrains plugin
• claude.ai/code in a browser
• The Claude iOS or Android app

The following commands should work regardless of originating surface:

• claude --remote — offload current session to cloud execution
• /teleport — pull a session into the local terminal
• claude remote-control / /rc — expose the session for remote access from another device

Additionally, when a session is handed off to a different environment (e.g. desktop app → terminal, or local → cloud), Claude should be context-aware about what changed — acknowledging differences in filesystem access, MCP server availability, tool permissions, etc. — rather than silently assuming the environment is identical.

Alternative Solutions

Currently there is no workaround short of starting a new session and manually re-establishing context. When a task has meaningful conversational history and environment-specific dependencies, this is not acceptable.

Workaround attempted: starting claude remote-control from the CLI in the same project directory does not resume or connect to the in-progress desktop app session — it starts a new isolated session.

Priority

High - Significant impact on productivity

Feature Category

CLI commands and flags

Use Case Example

1. I start a complex coding task in the Claude desktop app. The task has local dev environment dependencies (custom MCP servers, local filesystem, specific tooling) so cloud execution is not appropriate.
2. I want to step away from my desk and monitor/steer the task from my phone using Remote Control.
3. Because the session originated in the desktop app rather than the CLI, /rc is unavailable. There is no path forward except abandoning the session and starting over.

The fix is architectural: all surfaces should read from and write to the same session store, with Claude surfacing any environment differences on handoff.

Additional Context

Related issue: #29006 — Enable Remote Control for Claude Code sessions in Claude Desktop App (open, narrower scope — Remote Control only).

This request covers the full picture: --remote, /teleport, and remote-control should all be surface-agnostic. The underlying fix is the same in all cases: unified session storage across surfaces.