{"slug": "why-i-use-7-iterm2-autossh-tmux-and-chrome-remote-desktop-from-the-macbook-to", "title": "Why I Use #7: iTerm2, autossh, tmux and Chrome Remote Desktop — From the MacBook to the Machines", "summary": "A blog post in the \"Why I Use\" series details a terminal stack of iTerm2, autossh, tmux and Chrome Remote Desktop connecting a MacBook to Arch Linux workstations and rack servers that run coding agents. The author uses iTerm2's badge watermark to label each agent tab and iTerm2 3.7's Claude Code integration to show whether each Claude session is working, waiting or idle, while autossh restarts dropped ssh connections and tmux preserves the session across reconnects. The setup runs one unprivileged user per agent, with a shell alias such as `autossh -M 0 -t large12 \"tmux attach-session || tmux new-session\"` returning the author to the running session in one command.", "body_md": "# Why I Use #7: iTerm2, autossh, tmux and Chrome Remote Desktop --- From the MacBook to the Machines\n\n*1531 words • 8 min read* • Abstract\n\nThe [prior post](https://blog.softwarewrighter.com/2026/11/02/why-i-use-coding-agents/) in this series was about coding agents. This one is about what they run inside: the terminal stack between my MacBook and the Arch Linux workstations and rack servers where the agents work. Three terminal tools, each covering a different way a session can die, and one remote desktop for when a terminal is not enough.\n\n| Resource | Link | \n|---|---|\n| **iTerm2** | [iterm2.com](https://iterm2.com/) | \n| **autossh** | [harding.motd.ca/autossh](https://www.harding.motd.ca/autossh/) | \n| **tmux** | [github.com/tmux/tmux](https://github.com/tmux/tmux) | \n| **Chrome Remote Desktop** | [remotedesktop.google.com](https://remotedesktop.google.com/) | \n| **How the agents use it** | [AI Tools #4](https://blog.softwarewrighter.com/2026/05/16/pi-minimal-agent/) ,[Saw #7](https://blog.softwarewrighter.com/2026/04/19/saw-prolog-many-agents-self-hosting-mlpl/) | \n| **The longer timeline** | [TBT #13: Many Decades of Learning the Next Thing](https://blog.softwarewrighter.com/2026/10/01/tbt-timelines-of-tools/) | \n| **The series** | [Why I Use: every post](https://blog.softwarewrighter.com/series/#why-i-use) | \n| **Comments** | [Discord](https://discord.com/invite/Ctzk5uHggZ) | \n\n## Still pretending to be a VT100\n\n[My timeline of tools](https://blog.softwarewrighter.com/2026/10/01/tbt-timelines-of-tools/) starts its terminals row with an IBM 2741, a typewriter, and runs through the 3270 and the VT100. Everything I use today is still pretending to be the last of those. What has changed is what sits around the terminal: the connection is now something that should come back after a closed laptop lid, and the session is something that should survive the connection.\n\n## The setup\n\nFrom the MacBook, I connect with autossh to an Arch Linux machine, log in as an unprivileged user (one per agent), and run tmux. One tmux window runs the agent; another is a shell prompt, or sometimes an Emacs shell ([AI Tools #4](https://blog.softwarewrighter.com/2026/05/16/pi-minimal-agent/)). The same arrangement runs every agent, so what changes between them is the agent and not the setup.\n\n## iTerm2: the Mac end\n\niTerm2 is the terminal I choose to use on my Macs.\n\nMainly I use it for its watermark, which iTerm2 calls a badge: large, faint text in the corner of each session that shows what that tab is working on. With an agent in every tab, a glance tells me which is which.\n\nLately there is a second reason: iTerm2 3.7 added a [Claude Code integration](https://iterm2.com/claude-code-integration.html), which shows the status of every Claude session (working, waiting or idle) on its tab.\n\n## autossh: a connection that comes back\n\nssh is a TCP connection: close the laptop, change Wi-Fi, or let the network drop for long enough, and it is gone. [autossh](https://www.harding.motd.ca/autossh/) starts ssh, watches it, and starts it again when it exits or stops passing traffic. It is still plain ssh, with the same keys, config and port forwards, so there is nothing new on the server.\n\nA reconnect is not seamless: the old connection is gone and a new one takes its place. That is fine, because the work was never in the connection. It is in tmux.\n\nI connect with a shell alias. This one is for large12:\n\n```\nalias mlarge12='autossh -M 0 -t large12 \"tmux attach-session || tmux new-session\"'\n```\n\n- `-M 0` turns off autossh’s own monitoring port, so it restarts ssh whenever ssh exits.\n- `-t` gives the remote command a terminal, which tmux needs.\n- `tmux attach-session || tmux new-session` re-attaches to the session that is already running, or starts one if there is none.\n\nSo one command takes me from the Mac straight back into whatever was running, and a reconnect lands in the same place.\n\nI used [mosh](https://mosh.org/), the mobile shell, before it. mosh keeps a session alive across sleep and changes of network instead of reconnecting, which is the better idea on paper. In practice it proved unreliable for me, and lately it refuses to connect from my Mac at all. Local and cloud LLMs suggested plenty of diagnostics and proposed causes that turned out to be wrong, and none of them got mosh working reliably. autossh is less clever, and it works for me, so far.\n\n## tmux: a session that survives the connection\n\nautossh brings the connection back; tmux keeps the work alive while it is gone. Sessions live on the server, so a reboot of the MacBook, a new client, or a different machine can re-attach to the same running agent. That is what made [multi-day agent runs](https://blog.softwarewrighter.com/2026/04/19/saw-prolog-many-agents-self-hosting-mlpl/) on the Arch host practical: the agent keeps working whether or not anything is connected to it, and it can be inspected from wherever I am.\n\nI use tmux with a config of my own, and typically with two windows: one running a coding agent, the other a shell.\n\nI connect this way to many different users on the target machines, not just my main one. Those other Linux logins have reduced privileges: they cannot change anything on GitHub, cannot push, and cannot edit each other’s cloned repositories. Each agent works in its own login, and the worst it can do stays there.\n\n## Before tmux\n\nBefore tmux, Emacs did most of this for me. Its windows split one frame into panes, and a long-running Emacs held my buffers and shells while I came and went: `emacsclient` connected to that running Emacs instead of starting a new one, and [TRAMP](https://www.gnu.org/software/tramp/) let it edit files and run shells on remote machines. I sometimes used GNU screen.\n\n## Chrome Remote Desktop: more than a terminal\n\nSome work needs the remote machine’s screen, not just its prompt. For that I use [Chrome Remote Desktop](https://remotedesktop.google.com/) to reach the desktops of the Arch Linux workstations and rack servers from my MacBook.\n\nIt lets me do more than the CLI can. I can preview graphics on the machine that made them, and browse local servers in the remote desktop’s own browser, where a server listening only on that machine is just a local URL.\n\nThe desktop on the other end is [Xfce](https://xfce.org/), a lightweight one, which I chose for its simplicity and responsiveness, and because it uses fewer resources than a heavier desktop would.\n\n## Three ways to lose a session\n\nThe terminal is still pretending to be a VT100. What has changed is everything around it: a Mac that tells me which agent needs me, a connection that comes back on its own, sessions that never noticed it was gone, and a whole desktop when a prompt is not enough. A future post in this series is about what I type at that prompt: fd, ripgrep, skim, dua and bat.\n\n*Part 7 of the Why I Use series. [View all parts](https://blog.softwarewrighter.com/series/#why-i-use)*\n\n*Comments or questions? [SW Lab Discord](https://discord.com/invite/Ctzk5uHggZ) or [YouTube @SoftwareWrighter](https://www.youtube.com/@SoftwareWrighter).*", "url": "https://wpnews.pro/news/why-i-use-7-iterm2-autossh-tmux-and-chrome-remote-desktop-from-the-macbook-to", "canonical_source": "https://blog.softwarewrighter.com/2026/11/03/why-i-use-iterm2-tmux-autossh/", "published_at": "2026-11-03 08:15:00+00:00", "updated_at": "2026-11-03 16:20:46.851904+00:00", "lang": "en", "topics": ["ai-agents", "developer-tools", "ai-tools"], "entities": ["iTerm2", "autossh", "tmux", "Chrome Remote Desktop", "Claude Code", "Arch Linux", "mosh", "MacBook"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/why-i-use-7-iterm2-autossh-tmux-and-chrome-remote-desktop-from-the-macbook-to", "markdown": "https://wpnews.pro/news/why-i-use-7-iterm2-autossh-tmux-and-chrome-remote-desktop-from-the-macbook-to.md", "text": "https://wpnews.pro/news/why-i-use-7-iterm2-autossh-tmux-and-chrome-remote-desktop-from-the-macbook-to.txt", "jsonld": "https://wpnews.pro/news/why-i-use-7-iterm2-autossh-tmux-and-chrome-remote-desktop-from-the-macbook-to.jsonld"}}