Rex 让终端会话留在服务器，关掉窗口也不必打断工作

Rex 想改变的不是终端里输入命令的方式，而是任务与窗口之间的关系。 Superlogical 在 10 月 5 日宣布开始邀请用户参加 Rex 的公开测试，首轮测试限于 macOS 应用；它所强调的持久会话，让工作留在 Rex 服务器上，由客户端窗口接入，而不是把窗口本身当成工作的容器。但这里的「持久」有条件：服务器如何运行、谁能接入，决定了你关掉窗口后究竟还能接回什么。

先别把它读成一次稳定版发布。官方的 公开测试公告说的是邀请名单分批进入测试，团队此前约有 50 人参加私测；这些测试安排与「已向所有人开放」「稳定性经过独立验证」都不是一回事。现行安装文档的可用范围已经比公告当天所写的首轮更宽，下面会把两张时间截面分开。

关掉终端窗口，任务到底留在哪里？

设想你在一台机器上启动一个需要持续观察的构建任务，随后切到另一块屏幕处理代码。传统使用习惯容易让人把「关掉这个终端窗口」和「任务结束」联想在一起，于是为了不丢上下文，窗口越留越多。Rex 的切入点是把显示与运行拆开：客户端负责呈现和输入，服务器管理会话与其中的程序。你可以理解为窗口是一扇门，而不是存放工作的房间；门关了，房间是否还在，要看服务器和会话是否还在。

这不是对所有断线、崩溃或重启场景的恢复承诺。官方公告把 persistent sessions 列为 Rex 的能力，并说明 macOS 应用自带本地服务器，也能连接其他 Mac 上的 Rex 服务器。因此，初期最直观的场景是多台 Mac 之间接续同一台服务器上的工作，而非「任何手机现在都能接管电脑的终端」。至于关闭 Mac 应用、机器休眠或重启后每一个程序的具体行为，本文没有下载安装验证，不把结构推论写成实测结论。

另一层变化是可观测性。一个长期运行的终端任务不只是留下一大段滚动日志；官方公告还把程序活动状态列为产品能力。它听起来朴素：当窗口重新接入时，开发者首先想知道「那个任务还在跑吗」，然后才是「最后几行输出是什么」。这是厂商描述，状态显示仍应以任务日志或进程检查复核。

从 10 月的 Mac 邀请，到现行安装页有哪些变化？

两份官方材料放在一起读，才不会让日期和可用范围打架。

10 月 5 日公告的「What is available」写得很清楚：公开测试最初只限 macOS 应用。它当时提到已有 Linux、Windows 服务器，以及 iOS、Linux、Windows 客户端处于不同准备阶段，但明确说这些不在首轮测试中。「已经内部运行」与「测试者已经拿到」是两件事。

现行 Rex 安装页则称，当前 beta 阶段 macOS 应用以及 Linux、FreeBSD 服务器对测试者开放；Linux 与 FreeBSD 在该页都标为 Server only。Mac 客户端自带本地服务器；Windows 服务器虽已运行，iOS、Linux、Windows 客户端仍不在当前公开测试范围。这说明可供测试的服务端平台不止 10 月初公告的 Mac，但文档没有给出这里所述范围的确切更新日，不能把 FreeBSD 或 Linux 的开放时间倒填成 10 月 5 日。

对于「现在能否试」这个问题，更稳妥的判断是按角色拆开：想要桌面客户端，目前看 Mac；想在另一台机器运行服务器，可以看现行安装页列出的 Linux/FreeBSD 服务器条件；想用手机或 Windows 桌面客户端，不要仅凭「正在开发」就安排工作流。文档页面展示邀请及测试者登录入口；我们没有登录，也没有核查实际下载流程，因此这里不提供可直接照做的安装步骤。

持久会话也有服务器生命周期

一旦把任务放在服务器上，新的问题不是「窗口是否漂亮」，而是「服务器由谁运行、何时会停」。Rex 的 Linux/FreeBSD Server Modes 文档给出三种模式：personal 服务以当前用户身份运行；shared 服务以共同的 rex 账户运行；login 入口识别连接者，再把连接交给相应账户下的服务。它们不只是部署方式差异，也决定了会话在操作中会不会消失。

例如，personal 服务由 rex 命令自动启动时，最后一个会话和最后一个连接都关闭后，它大约十秒后自动退出；显式启动的服务则会继续运行。注意这里是两个条件同时成立，不是「关掉一个窗口就十秒清空所有工作」。同一文档也直说，执行服务停止操作会结束该服务上的所有会话。窗口关闭能否无缝接续，不能脱离这个进程生命周期独立讨论。

多人共享的 shared 模式更值得小心。所有被加入共享组的人都能查看、输入该服务器的所有会话，所有程序也在同一个 rex 账户下运行；服务停止会结束所有会话，软件包升级引发的服务重启也会如此。它适合相互信任且愿意共用身份的少数人，而不是靠「多用户」三个字就能给每个人隔出独立权限。

login 模式让不同账户拥有各自的服务。官方文档说，login 入口服务停止、重启或升级时，各账户服务仍运行，会话可跨这三种入口变动留存；这不等于账户服务自己被杀掉、机器宕机或断电之后程序也会自动恢复。该模式还依赖账户映射与连接来源身份，配置成本高于个人模式。上述生命周期事实来自 Linux/FreeBSD 文档，不应直接套到 macOS 应用内部服务器的每一种操作上。

所谓持久会话，最有价值的读法是「把窗口的命运与服务器内的会话分开」，不是「把服务器本身从故障域里删除」。团队若准备把长任务交给它，仍需按自己的机器、服务模式和任务检查点设计恢复路径，而不是先假定终端产品会包办一切。

远程接入时，访问服务器意味着什么权限？

跨设备接续的前提是允许另一台设备连接。Rex 的 Remote Access 文档明确说，Linux/FreeBSD 服务器默认只监听本机 Unix socket，也就是供本机进程连接的套接字；要从另一台电脑接入，必须另行配置网络监听。厂商当前推荐通过 Tailscale 识别连接者并使用网络访问控制——它在这里承担远程设备身份与网络访问控制的角色。网络可达不等于安全边界已经完备：官方也直言，当前主要依赖「如何连接」来信任调用者，更完整的认证和授权系统仍在计划中。

这里有一句比功能清单重要的警告：连接到一台服务器，就能做那台服务器能做的事，包括以其账户启动程序。shared 模式的共同账户、login 模式的身份映射，因而不仅是便利性选择，也是权限范围选择。不要把「可以自托管」直接翻译成「任何远程连接方式都安全」；也不要为了省去身份识别步骤，关闭原有的安全确认或给不可信网络暴露终端控制面。

获邀的 macOS 测试者可以先用非敏感短任务，检查关窗重连后进程和输出能否接续，再分别记录客户端断开、服务停止和机器重启的结果。这是建议的待测清单，不是本站已测结果；涉及重启的验证应选可中断的测试环境。团队共享或远程推广，则先确定谁应能访问哪些程序，再核定服务模式和网络身份策略。

本文没有执行配置或安全测试。终端程序常常拥有项目文件、环境变量和操作权限，访问控制需要按实际使用环境验收。

Agent 是另一个操作者，不是权限魔法

Rex 还有一条与编码工作流有关的线索。它的 Agents 文档描述了一个内置 agent skill：agent 可以通过 rex CLI 开标签、分屏、读取终端屏幕、向程序输入命令，也可以控制已连接的 Rex app。文档举的场景包括在另一标签运行开发服务器、并排运行测试，或者向已有的数据库终端输入命令。这些是官方给出的使用例子，不是我们在真实项目中验证过的成功案例。

操作前必须确定目标会话和窗格。 文档提供了定位线索：在 Rex 内启动的 agent 可用 REX_SESSION 与 REX_BLOCK 找到自己的会话和窗格；用户明确点名会话时，以名字为准。在 Rex 外启动、缺少定位信息且目标有歧义时，应先列出会话并请用户选择。同一个「运行测试」指令，落在当前窗格或共享机器上另一会话，后果可能截然不同。

官方还给一个明确开关：要求 agent 改变 Mac 应用本身的动作——例如让应用显示某个会话——需要应用正在运行且启用了 Remote Control。这是功能前提，不意味着开启后 agent 的每一个命令都会自动得到单独批准，也不意味着远程服务器的权限问题随之消失。特别是执行命令或输入交互程序时，仍应遵守所用 agent 自身的授权和确认机制，并保留人能理解的目标指向。

Rex 值得关注，是因为它把终端从「当前这扇窗口」重画成「可接入的工作会话」。眼下能成立的判断是：它已经进入分批公开测试，macOS 客户端与现行文档列出的 Linux/FreeBSD 服务端有明确边界，agent 控制也有条件。 至于换设备后哪些程序能连续运行、断线恢复的体验如何，仍需在对应环境实际试用。团队网络权限则需按现有连接身份与网络访问控制规则验收；原生完整认证授权仍在计划中，不等于当前无法建立访问控制。产品公告不能替代这些验收。