Remote MCP Server Setup Guide: Access Claude Code and AI Agents From Anywhere

March 23, 2026 | Amurg

mcp claude code remote access tutorial developer tools

You have Claude Code running on your workstation. You are on the train with your phone. You want to check what it is doing, approve a file change, or start a new task. How do you get there?

This guide covers every practical approach to remote AI agent access in 2026 --- from Claude Code’s built-in remote control, to SSH tunneling, to purpose-built control planes. We will be technically specific about what each approach involves, what it costs in complexity, and when you would choose one over another.

Background: What Is MCP?

The Model Context Protocol (MCP) is Anthropic’s open standard for connecting AI models to external tools and data sources. Think of it as a standardized way for an AI agent to say “I need to read this file” or “I need to call this API” without the tool integration being hardcoded into the model.

MCP uses a client-server architecture:

MCP Server: Exposes tools and resources (file access, database queries, API calls) over a standardized protocol
MCP Client: The AI agent (Claude Code, for example) that discovers and calls tools on MCP servers
Transport: Communication layer between client and server, typically stdio (local) or HTTP with Server-Sent Events (remote)

For local development, MCP servers usually run as subprocess spawned by the agent --- the transport is stdio and everything happens on the same machine. But MCP also supports remote servers over HTTP, which is where remote access gets interesting.

MCP in the Context of Remote Agent Access

When people search for “remote MCP server,” they usually mean one of two things:

Running an MCP server on a remote machine so that a local Claude Code instance can access remote tools (databases, APIs, file systems on other machines)
Accessing a Claude Code session itself remotely --- controlling the agent from a different device

These are different problems. This guide covers both, but focuses primarily on the second: how to control your AI coding agents from anywhere.

Approach 1: Claude Code’s Built-In Remote Control

Claude Code includes a native remote control feature that works well for single-user, single-agent scenarios.

How It Works

Start Claude Code on your workstation normally
Run /remote in the Claude Code session
A QR code appears in your terminal
Scan the QR code with your phone’s camera
A web-based interface opens, connected to your running session

Under the hood, this creates an authenticated WebSocket connection between your phone’s browser and the Claude Code process on your workstation, relayed through Anthropic’s servers.

Setup

There is no setup. It works out of the box with any Claude Code installation. This is its biggest advantage.

# Start Claude Code
claude

# Inside the session, enable remote control
> /remote

# Scan the displayed QR code with your phone

Limitations

Single agent only. This works for Claude Code. If you also run Copilot CLI or Gemini CLI, you need separate solutions for those.
Single user. The QR code grants access to one session. There is no multi-user access control.
No persistent sessions. If the Claude Code process stops, remote access stops. There is no session recovery.
Relies on Anthropic’s relay. The WebSocket connection goes through Anthropic’s infrastructure. If their relay is down, remote control is unavailable.
No audit logging. Actions taken through remote control are not separately logged from local actions.

When to Use It

Claude Code’s remote control is the right choice when:

You only use Claude Code (no other agents)
You are the only person who needs access
You are fine with session lifetime tied to the process
You want zero setup

For anything beyond that, you need one of the approaches below.

Approach 2: SSH Tunneling

The most common developer approach to remote access: SSH into the machine and use a terminal multiplexer to reattach to agent sessions.

Basic Setup

# On your workstation: start a tmux session with Claude Code
tmux new-session -s claude
claude

# Detach with Ctrl+B, D

# From your phone (using Termius, Blink Shell, or similar SSH app):
ssh your-workstation
tmux attach -t claude

SSH + tmux for Multiple Agents

# Create named sessions for each agent
tmux new-session -d -s claude 'claude'
tmux new-session -d -s copilot 'gh copilot'
tmux new-session -d -s gemini 'gemini'

# List active sessions
tmux list-sessions

# Attach to any session
tmux attach -t gemini

Making SSH Accessible From Outside Your Network

If your workstation is behind a NAT (which it almost certainly is), you need to make it reachable. Options:

Port forwarding on your router:

# Forward external port 22 (or a custom port) to your workstation's local IP
# This varies by router — check your router's admin interface
# Then connect with:
ssh -p 2222 user@your-public-ip

Reverse SSH tunnel through a VPS:

# On your workstation (runs once, keeps connection alive):
ssh -R 2222:localhost:22 user@your-vps -N

# From anywhere, connect through the VPS:
ssh -p 2222 user@your-vps

Limitations

Terminal on mobile is painful. Even the best mobile SSH apps are a poor experience for interactive agent control. Typing complex commands on a phone keyboard is slow and error-prone.
No unified view. You switch between tmux sessions manually. There is no dashboard showing what all agents are doing.
Security concerns with SSH port exposure. Opening SSH to the internet, even on a non-standard port, is a constant target for brute-force attacks. Key-only auth is mandatory, fail2ban is strongly recommended.
No RBAC. Anyone with SSH access has full access to everything.
No audit trail beyond shell history and SSH auth logs.

When to Use It

SSH tunneling is the right choice when:

You are comfortable with terminal interfaces on mobile
You only need occasional remote access, not daily
You already have SSH infrastructure set up
You do not need multi-user access or audit logging

Approach 3: Tailscale (or WireGuard)

Tailscale creates a private mesh network between your devices, so your workstation is reachable from your phone without port forwarding or VPS relays.

Setup

# On your workstation
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

# On your phone
# Install Tailscale from App Store / Play Store
# Sign in with the same account

# Your workstation is now reachable at a stable IP (e.g., 100.64.x.x)
# or by MagicDNS name (e.g., workstation.tail1234.ts.net)

Tailscale + SSH

# From your phone (with Tailscale connected):
ssh [email protected]
tmux attach -t claude

Tailscale + Web-Based Terminal

For a slightly better mobile experience, you can expose a web terminal over Tailscale:

# Install ttyd on your workstation
sudo apt install ttyd

# Start a web terminal (only accessible over Tailscale)
ttyd -p 7681 tmux attach -t claude

# Access from your phone's browser:
# http://workstation.tail1234.ts.net:7681

Tailscale Funnel for Remote MCP Servers

If your goal is to expose an MCP server to a remote Claude Code instance (not control a local Claude Code remotely), Tailscale Funnel can make a local MCP server available over HTTPS:

# Run your MCP server locally
python my_mcp_server.py --port 8080

# Expose it via Tailscale Funnel
tailscale funnel 8080

# Your MCP server is now at:
# https://workstation.tail1234.ts.net/

You can then configure a remote Claude Code instance to connect to this MCP server URL.

Limitations

Network layer only. Tailscale solves the “how do I reach my machine” problem. It does not solve the “how do I control agents from mobile” problem. You still need SSH or a web terminal on top of it.
Still terminal-based. The mobile experience is raw terminal, same as SSH.
Tailscale account required on all devices. Every device needs the Tailscale client installed and authenticated.
No agent awareness. Tailscale does not know you are running AI agents. It is a VPN, not a control plane.

When to Use It

Tailscale is the right choice when:

You want secure network access to your workstation without port forwarding
You are combining it with another tool for the actual agent interface
You have multiple machines you want to reach from mobile
You value the simplicity of Tailscale’s setup over traditional VPN configuration

Approach 4: Remote MCP Server Over SSE

For the specific use case of making tools available to a remote Claude Code instance, you can run an MCP server that communicates over HTTP with Server-Sent Events.

How It Works

You write a Python MCP server using the mcp package with an SSE transport, deploy it behind a reverse proxy with TLS (Caddy makes this trivial), and point Claude Code at the URL in ~/.claude/mcp.json. The MCP SDK’s SseServerTransport handles the protocol; you just define your tools as decorated async functions.

Security Considerations

MCP’s SSE transport does not include built-in authentication. You must add it yourself:

Run behind a reverse proxy with TLS (Caddy, nginx)
Add bearer token or OAuth middleware to your server
Restrict which tools are exposed
Log all tool invocations

Without these, you are exposing arbitrary command execution over the internet.

Limitations

This exposes tools, not agent sessions. A remote MCP server lets a Claude Code instance use remote tools. It does not let you control Claude Code itself remotely.
No built-in auth. You must add authentication yourself.
SSE transport limitations. Server-Sent Events are one-directional (server to client). The MCP SSE transport uses SSE for server-to-client messages and HTTP POST for client-to-server messages. This works but is less efficient than WebSocket.

When to Use It

Remote MCP servers are the right choice when:

You want Claude Code (running locally) to access tools on a remote machine
You need to give an agent access to production databases, monitoring systems, or deployment tools without running the agent on the production machine
You are building a tool-sharing infrastructure for a team

Approach 5: Purpose-Built Agent Control Plane

The approaches above each solve a piece of the remote agent access problem. A purpose-built control plane solves the full problem as a single, integrated system.

Architecture

The typical control plane architecture uses outbound-only WebSocket connections:

Your Workstation                    Control Plane Server
┌─────────────────┐               ┌──────────────────┐
│ Claude Code     │               │                  │
│ Copilot CLI     │──WebSocket──→ │  Session Manager │
│ Gemini CLI      │   (outbound)  │  Auth + RBAC     │
│ Codex CLI       │               │  Audit Logger    │
│                 │               │  Web/Mobile UI   │
│ Agent Runtime   │               │                  │
└─────────────────┘               └──────────────────┘
                                         ↑
                                    Phone / Tablet
                                    Browser Access

Key architectural decisions:

Outbound-only connections. The agent host connects to the server, not the other way around. No inbound ports need to be opened on the workstation.
Agent adapters. Each agent CLI (Claude Code, Copilot, Gemini, Codex) has a specific adapter that knows how to start, stop, send input to, and read output from that agent.
Session state on the server. The control plane maintains session state independently of the client connection. You can disconnect and reconnect from a different device.

What This Solves That Other Approaches Do Not

Unified multi-agent view. One dashboard showing all active agent sessions across all agents. Not N tmux windows, not N vendor apps.

Mobile-optimized interface. A proper web UI designed for mobile, with touch-friendly controls and voice input. Not a terminal emulator running on a phone.

RBAC. Define who can access which agent sessions and which actions require approval. Relevant for teams but also useful for solo developers who want to limit what agents can do unattended.

Audit logging. Every command, every file change, every approval --- logged in one place across all agents.

Session persistence. Network interruption, browser crash, device switch --- the session continues. Reconnect and the full state is there.

Amurg as an Implementation

Amurg is one implementation of this pattern. It provides:

Nine agent adapters (Claude Code, GitHub Copilot CLI, Codex CLI, Gemini CLI, Aider, Continue, Cline, Roo Code, and a generic CLI adapter)
Outbound-only WebSocket architecture
Session persistence across disconnects
RBAC with configurable permission levels
Full audit logging of all agent interactions
Mobile-first UI with voice input
Self-hosted deployment (Docker Compose)

Setup is a Docker Compose file:

git clone https://github.com/amurg-ai/amurg
cd amurg
cp .env.example .env
# Edit .env with your configuration
docker compose up -d

Connect your workstation by installing the agent runtime:

# On your workstation
pip install amurg-agent
amurg-agent connect --server https://your-amurg-instance.com --token YOUR_TOKEN

The agent runtime registers with the server over WebSocket, discovers locally installed agents, and makes them available through the control plane.

When to Use It

A purpose-built control plane is the right choice when:

You use multiple AI coding agents daily
You need mobile access that does not involve a terminal emulator
Session persistence matters (you start tasks and check back later)
You want RBAC or audit logging
You want a single interface for all agents

It is overkill when:

You only use one agent occasionally
You never need mobile or remote access
You are fine with terminal-based interfaces

Choosing Your Approach

Factor	Claude Code Remote	SSH + tmux	Tailscale	Remote MCP Server	Control Plane
Setup time	None	Low	Low	Medium	Medium
Mobile experience	Good	Poor	Poor	N/A (tool access)	Good
Multi-agent	No	Manual	No	No	Yes
Session persistence	Limited	Via tmux	Via tmux	N/A	Built-in
Security model	Anthropic relay	SSH keys	WireGuard	Custom auth	RBAC
Audit logging	No	Shell history	No	Custom	Built-in
Maintenance	None	Low	Low	Medium	Medium

For most solo developers starting out, Claude Code’s built-in remote control is enough. When you find yourself managing multiple agents, needing better mobile access, or wanting session persistence and audit logging, that is when a purpose-built control plane starts paying for itself.

The good news is these approaches are not mutually exclusive. You can use Claude Code’s remote control for quick checks, SSH for deep debugging sessions, Tailscale for network connectivity, and a control plane for daily multi-agent management. Use the simplest tool that solves each specific problem.