Every few months, someone announces a new terminal emulator that will revolutionize remote development. AI-powered this, cloud-native that. Meanwhile, iTerm2 has had a feature since 2012 that solves remote development better than most alternatives - and almost nobody uses it.

The Problem with SSH

If you do remote development, you know the pain:

  • SSH session dies, your work context vanishes
  • Scrollback is whatever fits in the terminal buffer
  • Copy/paste requires mental gymnastics (was that Cmd+C or did I just send SIGINT?)
  • Multiple sessions means multiple terminal windows to manage
  • Reconnecting means rebuilding your entire workspace

The standard fix is tmux. Run it on the server, attach/detach, sessions persist. But now you’re stuck with tmux’s text-mode interface: its scrollback, its copy mode, its keybindings fighting with your local ones.

The Hidden Gem: tmux Control Mode

iTerm2 can speak tmux’s control protocol. When you run tmux with -CC (control mode), instead of rendering a text-mode interface, tmux sends structured commands to iTerm2. The result:

  • Each tmux window becomes a native iTerm2 tab
  • Native scrollback - scroll with your trackpad, not Ctrl-b [
  • Native copy/paste - Cmd+C just works
  • Native search - Cmd+F searches the buffer
  • Sessions persist on the server
  • Disconnect and reconnect - everything restores exactly

One command:

ssh server -t tmux -CC new-session -A -s main

That’s it. You now have a persistent remote workspace that feels like local tabs.

Breaking Down the Command

ssh server -t tmux -CC new-session -A -s main
  • ssh server -t - force TTY allocation (needed for tmux)
  • tmux -CC - start tmux in control mode
  • new-session - create a new session
  • -A - attach if session already exists (idempotent reconnection)
  • -s main - name the session “main” (or whatever you want)

The -A flag is key. Run this command whether you’re connecting fresh or reconnecting. If the session exists, you attach. If not, you create it. Same command, always.

The Setup

1. Create an Alias

# In .zshrc or .bashrc
alias tbox="ssh box -t tmux -CC new-session -A -s main"

One command to connect to your dev server. Session persists across disconnects. Done.

2. Create a Dedicated iTerm2 Profile

I keep a separate profile for remote sessions:

  • Different background color (subtle, but enough to know where you are)
  • Larger scrollback buffer
  • Different title to show the hostname

Go to iTerm2 > Preferences > Profiles, duplicate your default, tweak the colors. When you’re three tabs deep in a debugging session, the visual distinction prevents “wait, which machine am I on?” moments.

3. Handle Multiple Servers

alias tbox="ssh box -t tmux -CC new-session -A -s main"
alias tprod="ssh prod -t tmux -CC new-session -A -s main"
alias tstaging="ssh staging -t tmux -CC new-session -A -s main"

Each gets its own persistent session. Different profile colors if you want extra safety.

What This Gives You

Persistence: Your laptop sleeps, WiFi drops, you close the lid and go home. Reconnect tomorrow, every tab is exactly where you left it. Long-running processes keep running.

Native scrollback: Scroll with your trackpad. Search with Cmd+F. Copy with Cmd+C. No mode switching, no tmux commands to remember.

Tab management: Cmd+T for new tab (creates tmux window on server). Cmd+W to close. Cmd+1/2/3 to switch. Drag to reorder. It’s just iTerm2.

Simplicity: No extra software to install (tmux is already on most servers). No cloud service. No subscription. No new tool to learn.

Trade-offs

This isn’t perfect for everything:

Single machine: You’re tied to iTerm2 on macOS. If you switch between Mac and Linux desktops, you can’t use control mode from Linux.

One client at a time: If you attach from two Macs simultaneously, things get weird. For shared sessions, use normal tmux.

Learning curve: If a colleague connects to your server with regular tmux, they’ll see the session but with different behavior. Worth documenting for your team.

Nested tmux: If you run tmux locally AND use this, you need to be careful about prefix key conflicts. I don’t run local tmux - this replaces it for remote work.

Why Not [Insert New Terminal]?

Every year brings a new “revolutionary” terminal:

  • Warp with its AI features
  • Ghostty (still in development at time of writing)
  • Various Electron-based options

Some are genuinely good. But each one is another tool to learn, configure, and trust with your workflow. iTerm2 + tmux:

  • Has been stable for 10+ years
  • Uses protocols and tools you already know
  • Doesn’t require trusting a new company with your terminal data
  • Works today, will work in 2030

The best tool is often the one you already have.

Quick Start

  1. Install iTerm2 (if you haven’t)
  2. Ensure tmux is on your server (apt install tmux or equivalent)
  3. Add the alias: 
    alias tbox="ssh yourserver -t tmux -CC new-session -A -s main"
  4. Run tbox
  5. iTerm2 will ask about tmux integration on first connect - accept it

That’s the entire setup.

Conclusion

  • The command: ssh server -t tmux -CC new-session -A -s main
  • What it does: Persistent remote sessions with native Mac tabs, scrollback, and copy/paste
  • Setup time: 2 minutes
  • New tools to learn: Zero (if you already know SSH and basic tmux)
  • Why it’s underrated: Apple’s documentation for this feature is buried, and tmux’s documentation focuses on the traditional text-mode experience

Remote development doesn’t need to be complicated. SSH and tmux have been solving this problem for decades. iTerm2 just made them work together seamlessly.

Related: Preserve macOS App Permissions Across Rebuilds - Keep your local dev tools working after code changes.