How I Run Claude Code from Anywhere

If you’ve used Claude Code (Anthropic’s CLI tool for working with Claude directly in your terminal, which I compared alongside other tools in my AI coding tools roundup), you know the drill. You spend twenty minutes getting Claude up to speed on your codebase, your conventions, your current problem. Then you close your laptop. Or switch to your work desktop. Or realize you need to check something from your phone during lunch. That session is gone. You’re starting over, explaining the same codebase to an AI that has already forgotten you exist.

That’s annoying enough for coding. But I use Claude Code for way more than writing functions. Through MCP servers (Model Context Protocol, a standard that lets Claude connect to external tools and services), I’ve hooked it into our project management setup for managing the team’s work. On any given day I’m using it to:

• Generate sprint task breakdowns from product backlog items
• Write task descriptions tailored to specific developers’ skill levels
• Draft onboarding checklists for junior team members
• Cross-reference time tracking entries with actual work completed
• Write meeting follow-up notes and next steps

Rebuilding that context every time I switch machines felt like paying rent on my own brain. I needed sessions that outlive my laptop’s lid.

Before getting into the setup, here’s the grocery list:

• A home server that stays on 24/7 (nothing fancy, an old mini PC running Arch that I probably should have thrown away)
• SSH for remote terminal access
• Tailscale (a mesh VPN built on WireGuard that creates a private network across your devices) for secure access from anywhere without punching holes in my router
• tmux (a terminal multiplexer that lets you run persistent sessions you can detach and reattach from any connection) for sessions that survive me slamming my laptop shut
• Claude Code running inside tmux
• MCP servers connecting Claude to project management tools, file systems, and other things
• Terminus (an SSH client for iOS and Android) for occasionally pretending I’m productive from my phone

Nothing exotic here. That’s the point. No single piece of this is impressive on its own, it’s just boring tools stacked on top of each other in a way that happens to be useful.

Most Linux distributions come with an SSH client installed, but the server component (the thing that accepts incoming connections) usually needs to be enabled. On Arch:

# Install OpenSSH if it's not already there
sudo pacman -S openssh

# Enable and start the SSH daemon
sudo systemctl enable --now sshd

On Ubuntu/Debian it’s sudo apt install openssh-server and the service starts automatically.

Once sshd is running, any machine on the same network can connect using ssh username@ip-address. You can find your server’s local IP with ip addr (look for the address on your main network interface, usually something like 192.168.x.x).

Test it from another machine on your local network first:

# From your laptop, on the same WiFi/LAN
ssh stephan@192.168.1.100

If that works, you’re in. If it doesn’t, check that sshd is actually running (systemctl status sshd) and that your firewall isn’t blocking port 22.

Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

The defaults are fine for testing, but you don’t want password authentication enabled any longer than necessary. Generate an SSH key on your laptop and copy it to the server:

# On your laptop (skip if you already have a key)
# Works the same on Linux, macOS, and Windows (PowerShell)
ssh-keygen -t ed25519

# Copy your public key to the server
# Linux/macOS:
ssh-copy-id stephan@192.168.1.100

# Windows (no ssh-copy-id, so do it manually):
# This reads your public key and appends it to the server's authorized_keys
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh stephan@192.168.1.100 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Once you’ve confirmed you can log in with the key (no password prompt), disable password auth on the server:

# On the server, edit /etc/ssh/sshd_config
# Set these values:
#   PasswordAuthentication no
#   PermitRootLogin no

# Then restart sshd
sudo systemctl restart sshd

At this point SSH works on your local network, but only your local network. To connect from outside (the office, your phone, a coffee shop), you need the server reachable over the internet somehow.

I tried port forwarding first. Opened port 22 on my router, set up dynamic DNS, the whole thing. It worked for about a week before I started seeing brute force attempts in my auth logs. Even with key-only auth and fail2ban, having an open SSH port on a residential IP felt like leaving a welcome mat out for script kiddies.

Tailscale (a mesh VPN built on WireGuard that creates a private network across your devices) fixed that. It gives all your devices private IP addresses in the 100.x.x.x range, and nothing is exposed to the public internet. No port forwarding. No DNS nonsense. Your server is reachable from anywhere you have Tailscale installed, and completely invisible to everyone else. I set it up in about ten minutes and immediately regretted the three hours I’d spent wrestling with my router.

Install on both your server and every device you want to connect from:

# On Arch Linux (server)
sudo pacman -S tailscale
sudo systemctl enable --now tailscaled
sudo tailscale up

For your client machines:

# macOS
brew install tailscale

# Ubuntu/Debian
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up

On Windows, download Tailscale from tailscale.com/download. It installs as a regular app with a system tray icon. On mobile, grab it from your app store.

Once all devices are logged into the same Tailscale account, they can reach each other directly. The whole thing takes about five minutes per device, most of which is spent typing your password.

After setup, run tailscale ip on your server to get its Tailscale IP address. That’s the address you’ll use from now on instead of the local 192.168.x.x one.

# ~/.ssh/config (or C:\Users\YourName\.ssh\config on Windows)

Host homeserver
    HostName 100.x.x.x  # Your server's Tailscale IP
    User stephan
    IdentityFile ~/.ssh/id_ed25519
    ServerAliveInterval 60
    ServerAliveCountMax 3

Now connecting from anywhere is just:

ssh homeserver

The ServerAliveInterval and ServerAliveCountMax settings send keepalive packets every 60 seconds, which stops your connection from silently dying when you walk away. When the connection does drop (and it will, especially on mobile), tmux keeps everything running on the server side. You just reconnect and pick up where you left off.

If you’ve never used tmux, the short version: it lets you create terminal sessions on the server that keep running no matter what happens to your SSH connection. You can disconnect, close your laptop, drive across town, SSH back in, and reattach to the exact same session. Every process still running, every scroll position preserved, like you never left. It’s basically hibernate for your terminal, except it actually works.

But tmux does more than just keep sessions alive. It’s a full workspace manager for your terminal, and understanding how it thinks makes it way more useful than just a crash-safety net.

Tmux has three layers of organization. It took me an embarrassingly long time to understand the difference, so here’s the version I wish someone had given me on day one:

Sessions are the top level. Think of a session as a complete workspace. I run one session per major context (work, personal, a specific client project). Each session lives on the server whether you’re connected or not.

Windows live inside sessions. They work like tabs in a browser. You can have a window for your editor, another for running tests, another for logs. You switch between them without losing anything.

Panes live inside windows. They split a single window into multiple terminal views. Side-by-side code and output, that kind of thing.

The hierarchy looks like this:

Session: "work"
├── Window 1: "claude"
│   └── Pane 1: Claude Code running
├── Window 2: "code"
│   ├── Pane 1: neovim
│   └── Pane 2: file watcher / build output
└── Window 3: "logs"
    └── Pane 1: tail -f on server logs

Session management (run these from your regular shell):

# Create a new named session
tmux new-session -s work

# Create a session in the background (detached)
tmux new-session -d -s personal

# List all running sessions
tmux list-sessions

# Attach to an existing session
tmux attach -t work

# Kill a session you don't need anymore
tmux kill-session -t old-project

Beyond the obvious “keep my session alive” thing, here’s why tmux is worth the learning curve:

Parallel visibility. I’ll have Claude Code running in one pane and the project’s file tree or test output in another. When Claude suggests a change, I can see the relevant code right next to it. No alt-tabbing, no “wait which file was that in.”

Background processes. Start a build, a test suite, or a long-running Claude task in one window, then switch to another and keep working. It’s all still going. Check back whenever.

Quick context switches. Prefix + s brings up the session picker. I can jump from my work session to a personal project in two keystrokes. Each session has its own windows, its own running processes, its own scroll history. Nothing bleeds between them.

Pair debugging. If a colleague needs to see what I’m looking at, they can SSH into the same server and attach to the same tmux session. Both of us see and type in the same terminal in real time. It’s like screen sharing for people who think GUIs are a crutch.

# ~/.tmux.conf

# Better prefix key (Ctrl+A instead of Ctrl+B)
unbind C-b
set -g prefix C-a
bind C-a send-prefix

# Mouse support (fight me)
set -g mouse on

# Bigger scrollback
set -g history-limit 50000

# Start window/pane numbering at 1, not 0
set -g base-index 1
setw -g pane-base-index 1

# Renumber windows when one is closed
set -g renumber-windows on

# Reduce escape delay (important for vim/neovim users)
set -sg escape-time 10

# True color support
set -g default-terminal "tmux-256color"
set -ag terminal-overrides ",xterm-256color:RGB"

# Don't rename windows automatically
set -g allow-rename off

I run separate tmux sessions for different work contexts:

# Create named sessions
tmux new-session -d -s work
tmux new-session -d -s personal
tmux new-session -d -s client-a    # Client project

# List all running sessions
tmux list-sessions

# Attach to a specific session
tmux attach -t work

With SSH and tmux handling the connectivity, Claude Code just needs to run inside a tmux session on the server. Install it, start it, and it sticks around as long as the session does.

# Attach to work session
tmux attach -t work

# Start Claude Code
claude

That’s it. Seriously. Claude Code is now running in a persistent session, and you can reach it from any device on your Tailscale network.

The part that surprised me most was how useful Claude gets when you connect it to external tools through MCP. I have MCP servers configured for our project management platform, and it basically turned Claude from “AI that writes code” into “AI that also does half my project management.”

The setup uses Azure CLI for authentication, so there’s no API key to manage:

# Install Azure CLI and log in on the server
sudo pacman -S azure-cli
az login --use-device-code
az devops configure --defaults \
    organization=https://dev.azure.com/yourorg \
    project=YourProject

Once the MCP server is configured in Claude Code’s settings, Claude can query work items, create tasks, update descriptions, and pull sprint data directly. My daily routine with it usually looks like:

1. Ask Claude to pull the current sprint’s backlog items
2. Have it generate task breakdowns with estimated effort
3. Review and adjust the descriptions (especially for juniors, where I want more detail and context)
4. Push the tasks to the project management tool directly from the session
5. Later in the day, ask Claude to summarize progress and flag anything that looks stuck

One thing I stumbled into by accident: having Claude write task descriptions calibrated to specific developers. A senior dev gets a task that says “implement the webhook handler for order events, follow the existing pattern in OrderService.” A junior developer working on the same feature gets step-by-step guidance, links to relevant code, and a list of things to watch out for. Same work item, different level of hand-holding.

I wouldn’t call this a polished system. It’s more of a pattern I fell into that works surprisingly well. I keep notes about each team member’s experience level and areas they’re growing in, and Claude uses those to adjust its output. Saves me from writing onboarding-style descriptions by hand, which I’m honestly terrible at being consistent with.

Terminus (an SSH client for iOS and Android) on my phone connects to the home server through Tailscale, and I can attach to tmux sessions from the couch. This sounds way cooler than it actually is in practice.

It’s good for:

• Checking if a long-running task finished
• Reading Claude’s output from a question I asked earlier
• Quick “did the build pass” glances

It’s bad for:

• Actually typing anything longer than a sentence
• Reviewing code diffs
• Any real interactive work with Claude

I use it maybe two or three times a week, usually when I’m away from my desk and want to check on something. It’s a nice escape hatch, not a primary workflow. Don’t go into this expecting to do serious work from your phone. You will be disappointed and your thumbs will hurt.

I want to be upfront about the friction here, because reading this back makes it sound way smoother than my actual day-to-day experience.

Session management is manual. There’s no dashboard telling me which sessions are active or which Claude instances have been idle for hours. I just run tmux list-sessions and try to remember what each one was for. It works, but it’s held together by naming conventions and the fading remnants of my short-term memory.

Network hiccups happen. Tailscale is solid, but SSH connections over mobile networks still drop. The tmux reattach handles this fine (nothing is lost), but there’s always a few seconds of “is it frozen or just slow” anxiety after reconnecting.

Auth tokens expire. Azure CLI tokens have a shelf life, and when they expire, Claude’s project management connection quietly stops working. I’ve gotten better at recognizing the symptoms, but I still waste a few minutes every couple weeks wondering why a query returned nothing before remembering to run az login again.

The team is mid-transition. We’re moving from our current project management platform to custom-built software. That means my MCP setup is targeting a system we’re actively migrating away from. It still works fine for now, but I know the integration will need a rebuild when the new system is ready. Classic “building on top of the thing you’re replacing” situation.