第一次接触远程终端时，Shell、SSH、tmux 很容易被混成一回事：反正都要在黑色窗口里敲命令，它们到底有什么区别？
其实三者并不冲突，也不存在谁替代谁。它们解决的是三个不同的问题：
Shell 用来执行命令，SSH 用来连接另一台机器，tmux 用来保留那台机器上的终端会话。
把三者串起来，就是一套常见的远程开发环境。过去，人们用它运行脚本、查看日志或维护服务器；现在，Claude Code、Codex、OpenCode 这类 Coding Agent 会在终端里持续工作几十分钟甚至更久，这套组合也因此变得更重要。
Shell 是什么？
打开终端，你可能会输入 git status、npm run dev，或者直接用 claude 启动 Claude Code。
终端窗口本身不会理解这些命令。真正负责读取文本、解析语法、查找程序并启动进程的，是 Shell。
GNU Bash 手册将 Unix Shell 定义为命令解释器，同时也是一种编程语言。常见 Shell 包括 Bash、zsh 和 fish。
例如，输入 git status 后，Shell 会找到并启动 Git；输入 claude 后，Shell 会在当前目录和当前环境中启动 Claude Code。
因此，可以把 Shell 理解为：
你输入命令、运行开发工具的命令环境。
终端和 Shell 不是一回事
Ghostty、Terminal.app、iTerm2 属于终端应用，更准确地说是终端模拟器；Bash、zsh、fish 才是 Shell。以 Ghostty → zsh → git status 为例，Ghostty 提供输入输出界面，zsh 读取命令，Git 则是最终被启动的程序。
换句话说：
- 终端是你看到和操作的界面。
- Shell 是终端里真正接收命令的程序。
所以，更换终端 App 不一定会更换 Shell；同一个终端里也可以启动不同的 Shell。
SSH 是什么？
当代码就在眼前这台电脑上时，打开终端就能使用 Shell。但如果代码在家里的 Mac、办公室工作站、Linux 开发服务器或 VPS 上，就需要先连接那台机器。
SSH 做的就是这件事。
SSH 是 Secure Shell 的缩写，中文常译为“安全外壳协议”。虽然名字里也有 Shell，但 SSH 不是前文所说的命令解释器；它是一套用于安全远程登录和执行命令的网络协议。
OpenSSH 手册将 ssh 描述为远程登录客户端：它可以通过加密连接登录另一台机器，也可以直接在远程机器上执行命令。
最基本的用法是 ssh alice@development-host：电脑或手机先通过 SSH 到达远程 Mac 或服务器，再使用远程主机上的 Shell。
SSH 认证成功后，远程主机通常会为你启动一个 Shell。此后输入的命令看起来和本地终端很像，但程序实际运行在远程主机上。
所以，SSH 不是 Shell。SSH 只负责把你带到远程主机，Shell 才负责执行到达之后的命令。
如果你正在配置 Redock，可以先阅读 SSH Key 配置指南，把“如何安全登录”和“如何保留会话”分开处理。
SSH 断开后，正在运行的任务会怎样？
假设你从手机 SSH 到自己的 Mac，进入项目目录后直接运行 claude。Claude Code 开始读代码、修改文件和运行测试；几分钟后，你走进电梯，手机突然没有信号，SSH 连接也随之断开。
这时会出现两个问题：
- 手机已经无法继续操作刚才的交互式终端。
- 远程进程可能退出，也可能继续，但未必还能方便地回到原来的交互状态。
具体结果取决于 Shell、进程和启动方式，不能简单地说“SSH 一断，所有程序一定结束”。但有一点是确定的：如果任务只依赖当前这次连接，恢复现场会很麻烦。
对 ls 这种立即结束的命令来说，这不重要。但 Coding Agent 可能要连续读取几十个文件、修改代码、运行测试、修复失败，最后再等待你的决定。
这时丢失的不只是一条命令，而是一段已经运行了一段时间的开发上下文。
tmux 要解决的，就是把“手机是否连着”和“远程会话是否还在”变成两个独立问题。
tmux 是什么？
tmux 的全称是 Terminal Multiplexer，中文通常叫终端复用器。这个名字有些抽象，但核心思路并不复杂：
把终端会话留在远程主机上，而不是绑在当前手机或电脑上。
官方 tmux 入门文档说明，程序运行在 tmux 管理的终端中。外部终端可以先断开（detach），之后再从原来的终端或另一台设备重新进入（attach）。
tmux 不只保留一个终端窗口
“断开后还能回来”是 tmux 在远程 AI Coding 中最重要的价值，但不是它的全部。tmux 还把终端工作区组织成几个层级：
- Server：运行在开发机上的 tmux 后台服务，管理其中的会话。
- Session：一组可以命名、分离和重新接入的工作区，适合对应一个项目或一项长期任务。
- Window：Session 里的不同终端页面，类似标签页，可以分别放 Coding Agent、测试或日志。
- Pane：Window 内的分屏，每个 Pane 都可以运行自己的 Shell 和程序。
例如，一个 checkout-refactor Session 可以有一个 Window 运行 Claude Code，另一个 Window 跑测试；需要同时观察 Agent 输出和开发服务器日志时，也可以把一个 Window 分成两个 Pane。
这里最容易混淆的是“分离”和“退出”：detach 只是让当前手机或电脑离开 Session，其中的程序仍可继续运行；退出最后一个 Shell、终止 Session 或停止 tmux Server，则可能真正结束对应的工作区。对于 Redock 的移动工作流，通常只需要理解并使用 Session 的创建、查看、分离和重新接入，没必要先记住整套快捷键。
直接运行 Claude Code，和通过 tmux 运行有什么区别？
tmux 可以理解为运行在远程主机上的终端会话管理器。它不替代 Shell，也不负责执行 Claude Code；它负责管理承载 Shell 和 Claude Code 的那段终端会话。
直接在 SSH 终端中运行 claude，任务会依附于当前交互式连接。通过 tmux 运行时，Claude Code 仍然由 Shell 启动，但外面多了一层由远程主机持有的 tmux 会话：
# 直接在当前 SSH 终端中启动
claude
# 或先创建 / 进入 tmux 会话，再启动 Claude Code
tmux new-session -A -s coding
cd ~/projects/app
claude
两种方式运行的是同一个 Claude Code。区别不在 Agent 能做什么，而在它所在的终端会话由谁管理：直接运行时，会话更依赖当前 SSH 连接；通过 tmux 运行时，会话留在远程主机上，客户端断开后仍有机会重新进入。
此时，开发机上的结构是 tmux: coding → Shell → Claude Code。coding 会话属于开发机，手机和电脑只是连接它的客户端。
手机断开后，tmux 会话仍可留在主机上
下面这些情况都可能让当前连接暂时不可用：
- 手机锁屏或 App 进入后台；
- 网络短暂中断；
- SSH 连接断开；
- 在 Wi-Fi、4G 和 5G 之间切换。
只要开发机、tmux 服务和 Agent 进程仍然正常，这些变化影响的是手机到开发机的连接，而不是开发机上的 coding 会话。Claude Code 可以继续留在 tmux 中运行或等待输入。
网络恢复后，重新连接开发机，再运行 tmux attach-session -t coding 进入原会话。完整的恢复命令会在后面的实操部分统一展示。
你看到的是之前那段终端输出和 Agent 上下文，而不是一个全新的会话。
tmux 不是备份系统
tmux 能避免会话跟着客户端连接一起消失，但不能保证任务永远运行。
它仍然依赖：
- 开发机保持开机和唤醒；
- tmux 服务没有停止；
- Coding Agent 自身没有退出；
- 操作系统和存储环境正常。
如果开发机关机、重启，或者 tmux 服务停止，会话就可能消失。tmux 解决的是“客户端离开后还能回来”，不是所有主机故障。
把 Shell、SSH 和 tmux 放回一条远程连接链路
分别理解三个工具之后，再看它们在真实远程开发中的位置会更清楚。假设项目在家里的 Mac 上运行，而你人在外面，手上只有一部手机：
| 工具 | 实际作用 | 最简单的记法 |
|---|---|---|
| Shell | 读取命令并启动程序 | 干活的地方 |
| SSH | 安全地连接远程主机 | 去那里的路 |
| tmux | 把终端会话留在远程主机上 | 离开后还能回来 |
| Redock | 把连接、项目和会话整理成手机上的工作流 | 用手机控制整套流程 |
手机先通过 SSH 或 Mosh 连接开发机，再进入开发机上的 tmux Session；Session 的 Window 或 Pane 中运行着 Shell，Claude Code、Codex 或 OpenCode 则由 Shell 启动。
很多人会搜索“Shell vs SSH vs tmux”，但它们并不是真正的对手：
- 没有 Shell，命令无处执行。
- 没有 SSH 或 Mosh，手机无法到达远程开发机。
- 没有 tmux，长时间任务容易和一次临时连接绑在一起。
三者各自补上一块，才形成完整的远程终端工作流。
理解这条链路之后，下一步不是再记一遍概念，而是让它真正承载一项可以离开、也可以回来的 Coding 任务。
把连接链路变成可恢复的 AI Coding 会话
假设你准备让 Claude Code 处理一次结账流程重构，而且任务可能在你离开电脑后继续运行。下面的命令可以用于 Mac、Linux 开发机或服务器；整个过程只需要分成“开始任务”和“回来继续”两个阶段。
首次启动：连接、进入项目并运行 Agent
ssh alice@development-host
cd ~/projects/checkout
tmux new-session -A -s checkout-refactor
claude
# 也可以是 codex 或 opencode
这里的 -A 表示：如果 checkout-refactor 已经存在，就直接进入；如果不存在，就创建一个。Claude Code 会在这个 tmux 会话里使用当前项目目录和开发环境。
重新连接：找到并进入原会话
重新连接开发机后，先查看现有会话，再进入刚才的会话：
ssh alice@development-host
tmux list-sessions
tmux attach-session -t checkout-refactor
两段命令分别对应两个时刻：第一次用 SSH 到达开发机，在 tmux 中启动任务；之后再次连接，回到已经存在的会话。Shell 和 Coding Agent 始终运行在开发机上。
一个真实的远程 AI Coding 场景
假设你正在 Mac 上重构结账流程。你进入 checkout-refactor 会话并启动 Claude Code，告诉它：“重构 checkout validation flow，保持 public API 不变；为无效 coupon 补充 regression test，然后运行 checkout test suite。”
Agent 开始读文件、改代码、跑测试。任务还没结束，你已经离开电脑。稍后，你从手机通过 SSH 或 Mosh 重新连接 Mac。进入 checkout-refactor 会话后，你发现 Claude Code 已经完成大部分修改，只是在等你确认一个边界情况。你直接在原会话里回复，Agent 随即继续执行。
整个过程中，代码仓库、依赖、Git 状态和 Agent 进程一直留在 Mac 上。手机没有接管开发环境，只是让你在需要时重新回到现场。
这也是 保持长时间 AI Coding 会话运行这篇工作流文章所描述的场景。
会话留在开发机上以后，还有一个现实问题：手机并不会一直处在稳定网络中。你可能走进电梯、离开 Wi-Fi，或者在蜂窝网络之间切换。tmux 能保留会话，但它不负责改善手机到开发机之间的连接体验。
手机网络变化时，Mosh 补上什么？
Mosh是一种面向移动网络设计的远程终端。手机从 Wi-Fi 切换到蜂窝网络，或者网络短暂不可用时，Mosh 通常比普通交互式 SSH 更能适应这些变化。
可以这样区分：
- SSH 负责认证，并建立标准的安全远程连接。
- Mosh 改善移动网络下的交互体验。
- tmux 把会话和程序留在开发机上。
Mosh 和 tmux 不是二选一：Mosh 关注当前连接，tmux 关注主机上的会话。如果你的手机经常在不同网络之间移动，可以在 Redock 中选择 Mosh 作为连接模式；服务器和 UDP 要求可以查看 Mosh 配置指南。
这套做法也不是某个产品独有的设计。Termius 建议在手机上使用 AI Agent 时配合 tmux 和 Mosh，Moshi 也把 tmux 作为主机端的持久工作空间。产品体验不同，但底层仍然是标准的远程终端工具。
到这里，SSH 或 Mosh 配合 tmux，已经能完成远程连接和会话恢复。在电脑终端里，输入几条命令重新进入 Session 并不麻烦；但当你离开电脑，只想从手机看一眼 Agent 的进度、确认一个问题或补充一条指令时，重新选择主机、进入项目目录、查找 Session，再定位到正确的 Terminal，就会显得有些繁琐。
Redock 让这套流程更适合在手机上继续
Redock 正是用来简化这段操作的。它把主机、项目目录和远程会话组织成 Project，让你可以从项目上下文回到对应的 Terminal 或 tmux Session，再继续 Claude Code、Codex 或 OpenCode，而不必每次从连接命令重新开始。
因此，Redock 不是新的 Shell，也不替代 SSH、Mosh 或 tmux。底层工具仍然负责连接、保留会话和运行命令；Redock 负责让这套组合在手机上更容易找到、更容易继续。
在这套结构中：
- SSH 或 Mosh 让手机能够访问开发机。
- tmux 让远程终端不必依赖手机一直在线。
- Shell 在真实的项目环境中运行代码、脚本、测试和 Coding Agent。
- Redock 通过 Project、终端、Action、语音输入，以及可见的 tmux 创建和恢复入口，把这些操作组织成移动工作流。
Redock 连接的是你自己控制的开发机。代码、依赖、仓库、Shell 和 Agent 都不会因此搬到手机或 Redock 的云端。
当一个 Agent 正在等待确认时，你真正需要做的可能只是查看当前输出并给出一个决定。Redock 减少的是这次简短操作之前的准备步骤，尤其是在多个项目、主机和长时间任务之间切换时。
Redock 的 Project 可以保存主机与工作目录等项目上下文；tmux 功能则把常用的创建、进入和恢复操作放进产品界面。于是，你可以按“项目 → 会话 → Agent → 下一步操作”继续工作，而不是每次都从“主机 → 路径 → 会话名 → 命令”重新建立上下文。
底层仍然是开发机上的标准 tmux 会话。回到电脑后，桌面终端也能进入同一个会话，不会被锁在手机专用环境里。
主机端仍然使用标准 tmux 会话，具体配置可以查看 tmux 配置指南；Redock 中的创建、进入和恢复方式则可以在 tmux 功能中继续了解。
这套方案有哪些边界？
它解决的是远程连接与会话恢复，并不能覆盖所有故障：
- Redock 不会替代真正运行开发环境的 Mac、Linux 主机或服务器。
- Redock 不会把完整开发环境搬到自己的云端运行。
- 开发机关机、休眠或网络不可达时，手机无法正常连接。
- 主机或 tmux 服务停止后，tmux 无法继续保留会话。
- Mosh 也需要服务器和必要的网络路径重新可用，才能恢复连接。
这些边界不改变前面的分工：开发环境留在 Mac 或服务器上，SSH 或 Mosh 负责连接，tmux 保留会话，Shell 运行命令和 Agent，Redock 提供手机上的工作流入口。
Shell、SSH 和 tmux 常见问题
SSH 是 Shell 吗？
不是。SSH 负责安全地连接另一台机器；连接成功后，你通常会使用远程主机上的 Bash、zsh 等 Shell。OpenSSH 也支持不进入交互式 Shell，直接执行指定的远程命令。
终端和 Shell 是一回事吗？
不是。终端应用提供文字输入输出界面，Shell 则在终端中读取命令、解释命令并启动程序。
tmux 可以替代 SSH 吗？
不可以。tmux 只能管理某台机器上的终端会话，不能建立手机到远程主机的网络连接。你仍然需要 SSH、Mosh 或其他连接方式。
SSH 断开后，tmux 里的任务还会继续吗？
通常可以。SSH 客户端离开后，tmux 会话仍可留在远程主机上，其中尚未结束的程序可以继续运行。但前提是远程主机、tmux 服务和相关进程本身都还在运行。
开发机关机后，tmux 会话还在吗？
通常不在。tmux 依赖开发机和 tmux 服务保持运行，不能代替进程守护、备份或系统恢复方案。
Claude Code 或 Codex 必须使用 tmux 吗？
不需要。它们可以直接运行在普通终端里。只有当任务运行时间较长，而你可能断网、切换网络、关闭客户端或换设备继续时，tmux 才特别有用。
最后，用四句话记住它们
Shell：执行命令的地方。
SSH：连接开发机的方式。
tmux：离开后还能回来的会话。
Redock：从手机控制这套工作流的入口。
Shell、SSH 和 tmux 本来就是远程开发中很成熟的一套组合。AI Coding Agent 让一次终端会话承载的工作变得更长，也让“断开后还能回到原现场”比过去更有价值。
Redock 不替代这些工具，而是让它们在手机上更容易使用：开发机继续运行代码和 Agent，你只在需要查看、回复或作出决定时，从手机回到正在进行的任务。