# Rex: How Persistent Terminal Sessions Work Across Machines A coding agent can spend a long time working in a terminal, but its progress is tied to the machine running it. Closing a laptop may interrupt the work even when the model request itself is handled elsewhere. The local agent process still needs time to execute commands, read files, and receive responses. [Rex](https://www.superlogical.com/rex/docs/installation) separates the terminal interface from the server that owns its sessions. A client can display programs running on another computer and reconnect to them later. **The session's execution belongs to the host, rather than the window used to view it.** That is a familiar goal for users of terminal multiplexers, but Rex packages it with a graphical terminal experience and integrated remote access. The useful question is how the arrangement changes everyday work, which failures it survives, and where an established tool such as tmux remains a better fit. The product description groups session continuity and remote access with interface features. Those capabilities still need to be understood separately from any promise about speed or reliability. ![Rex product description groups persistent sessions, remote connections, and program activity status](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/ea4d8252-ba4f-4ad4-af37-53c80f3ccf00/lg1x =1920x1080) ## Why a terminal window and a running program are different things A terminal application displays output and sends input. The programs using it run as operating-system processes, often through a shell. They can include an editor, a test runner, a development server, or a coding agent. In a conventional interactive session, closing the terminal can disrupt the shell and its attached programs. The exact outcome depends on process behavior, terminal settings, and how jobs were started. It is too broad to say that every program always dies whenever a window closes, but ordinary terminal sessions are not a durable job-management system. A persistent-session layer changes the relationship. It keeps the program's terminal session on the host and lets a separate client attach to it. Disconnecting that client no longer needs to mean ending the program. This is different from restarting a failed job. If the process exits, its host reboots, or the application loses unrecoverable state, reconnecting to a terminal does not reconstruct everything that happened. Persistence across a client disconnect is a narrower guarantee than recovery from every machine or process failure. The distinction is especially useful for coding agents. An agent may be waiting for a model response in one moment and editing files or launching tests in the next. Keeping its interactive process attached to a durable host lets those operations continue without requiring a particular client window to remain visible. ## What tmux already solves [tmux](https://github.com/tmux/tmux/wiki/Getting-Started) is a terminal multiplexer. It maintains a server containing sessions, windows, and panes, and lets terminal clients detach and reattach. Programs inside those sessions can continue when an outside terminal disconnects. For a remote developer, the arrangement commonly combines Secure Shell (SSH) with a tmux session on the remote machine. SSH supplies the connection, while tmux supplies session ownership and organization. They solve related but separate problems. ![A terminal displays programs whose sessions are retained by tmux](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/d2071d1e-ffc0-47b8-5d8b-5345436fdf00/orig =1920x1080) An illustrative session name makes that ownership explicit: ```command tmux new-session -s agent-work ``` The command creates a named session on the machine where it runs. A later client can identify the same session rather than starting a new shell: ```command tmux attach-session -t agent-work ``` These commands describe the session model, not a required migration procedure. The process still runs on the tmux host. Creating tmux on a laptop does not move its work to a remote server or prevent the laptop from sleeping. tmux also presents a terminal interface within the outside terminal. Its pane layout, selection, copy mode, and key bindings can become another interaction layer to learn. That flexibility is useful across many environments, but it differs from an application that owns both the graphical presentation and the persistent-session connection. ![tmux processes application output and manages text selection before the outside terminal displays it](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/7bd5d41a-4c1b-4288-17b5-0869c17aee00/orig =1920x1080) ## How Rex divides the client and server Rex keeps a server responsible for sessions and a client responsible for the visible experience. The examined Mac showed the application and server as separate processes, with a session remaining after the application was quit. That observation supports the client/server separation; it does not establish behavior after a host reboot or every kind of server failure. ![Process listing identifies separate Rex application and Rex server processes](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/a8a99f89-973c-45b6-cc6d-b8e184df4a00/lg2x =1920x1080) After the client closes, the status response retains the server process identity and reports one session. That connects the process listing to retained server state, although the count alone does not establish that each program inside the session is healthy. ![Rex server status retains the same process identity and reports one session after the client closes](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/043660c8-09b8-4997-5fca-4119ac404000/lg2x =1920x1080) The graphical client uses the rendering technology associated with Ghostty. Its purpose is to make persistent sessions feel like part of the terminal application rather than a second text interface nested inside it. ![Rex separates the graphical terminal from the server retaining the agent and development server](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/2c2aa717-7cc7-400c-56d4-85b2d32bc400/md1x =1920x1080) Tabs and split panes organize the visible work. A shell, a coding agent, and a test process can occupy different areas while remaining part of a session hosted by the server. The application handles the interaction with those areas, including ordinary text selection and scrolling. ![Rex presents two shell panes within one graphical window, with tabs and pane controls above them](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/9eab8891-ebdd-4c36-0806-92b13c356a00/md2x =1920x1080) The visible layout and the execution lifecycle should still be understood separately. A pane can be displayed beautifully while the program inside it fails. Likewise, a program can remain active without any client currently displaying its terminal. The architecture's value lies in making those two lifetimes less dependent on one another. For local use, the [installation documentation](https://www.superlogical.com/rex/docs/installation) describes the macOS application as self-contained, including a local server. The same interface can also display a session owned by a different host, which is where the model becomes particularly useful for portable computers. ## Why a remote host can keep working while a laptop sleeps Consider a MacBook displaying a Rex session on a Mac mini. The Mac mini runs the shell and coding agent. The MacBook provides the client interface and network connection. Closing the MacBook removes the view, but it does not inherently suspend the process on the other computer. ![A Rex client on a MacBook connects through Tailscale to a Mac mini that owns the server and Claude process](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/65b3be7d-7b00-45b8-f827-bfef9885e600/md1x =1920x1080) The host's location is the important detail in the diagram. If the same agent ran on the MacBook instead, putting that laptop to sleep would normally suspend its opportunity to execute. Separating the window from the server cannot manufacture compute time on a sleeping machine. Remote persistence also does not automatically synchronize project files. A command executed on the Mac mini sees that machine's filesystem, dependencies, credentials, and environment. The client may display the session locally, but the work has not moved into the client's home directory. That can make the remote machine a useful stable development environment. It also means that diagnosing a failure requires checking the correct host. A missing executable, unavailable repository, or failed network request belongs to the environment executing the command, not necessarily the laptop displaying the error. The same distinction applies to agent permissions. A remotely hosted agent uses the authority available to its process on that machine. Session continuity should not be confused with restricted access or a sandbox around the agent's commands. ## What Tailscale contributes to the connection [Tailscale](https://tailscale.com/) provides private networking and device identity that Rex can use for remote access. In the examined arrangement, both computers participated in the same private network and the Rex client selected the remote host through its interface. The [Rex remote-access documentation](https://www.superlogical.com/rex/docs/linux/remote-access) describes several connection modes. Its built-in Tailscale mode uses a tailnet address and requires MagicDNS and HTTPS certificates. HTTPS protects web traffic with encryption and certificates that help clients validate the service they are reaching. Those requirements are part of the connection architecture, not evidence that the session is hosted by an unrelated cloud compute service. The program can remain on a computer the user controls while networking services help the client reach it. Authentication deserves separate attention. The current documentation says remote callers can exercise the server account's capabilities and describes restrictions based on the connection mode and identity. A private address is not, by itself, a reason to grant everyone on a network unrestricted terminal access. The account restriction is separate from enabling remote serving. Both controls affect who can reach a terminal that acts with the server account's authority. ![Detail of Rex controls for serving over Tailscale and restricting access to the same account](https://imagedelivery.net/xZXo0QFi-1_4Zimer-T0XQ/974c7449-d331-45ce-fafe-5441695da600/md2x =1040x205) The integrated connection can avoid manually opening an SSH session, but that should not be interpreted as a universal prohibition on SSH. Rex's documentation also describes SSH forwarding. The useful distinction is whether the product manages the connection for the user, not whether a particular transport can never be involved. ## How agents can interact with the terminal workspace An agent running in a persistent terminal remains a program like any other. Rex also exposes interfaces that let an agent operate the surrounding workspace, such as opening tabs, splitting panes, and reading terminal screens. The [agent documentation](https://www.superlogical.com/rex/docs/automate/agent-skill) describes a bundled skill and associated setup. Its command-line interface includes a setup command: ```command rex skill setup ``` This command illustrates the integration surface. It configures supported agents rather than starting an independent reasoning model inside Rex. Exact setup behavior depends on the installed version and the agent's own configuration. A useful example is an agent launching a development server in another terminal and examining its output. That creates a shared place for a person to inspect what happened. However, reading text from a terminal is not the same as validating that every application behavior is correct, and an instruction to manipulate a pane is not permission to act in any unrelated session. Persistent organization can make this workflow easier to supervise. The developer can reconnect and inspect the same session rather than rely only on the agent's final summary. The resulting visibility complements testing, code review, and explicit permission boundaries. ## Persistence has limits that a remote workflow must respect Several interruptions look similar from the client's perspective but have different consequences: | Event | What it means for the session | | --- | --- | | Client window closes | A server-owned session can remain available | | Client loses connectivity | The view is interrupted; host execution may continue | | Client laptop sleeps | Remote work can continue if its host remains active | | Execution host sleeps | Programs generally stop making progress while it sleeps | | Agent process exits | Reconnecting does not automatically restart the task | | Host or server fails | Recovery requires capabilities beyond client reattachment | This is why persistence is useful without being a complete reliability strategy. A remote coding task can still depend on external APIs, authentication, disk space, and service availability. Keeping the terminal alive does not guarantee those dependencies remain healthy. For unattended work, the important operational question is what happens when the task stops making progress. A persistent session gives a place to return, but monitoring, durable logs, checkpoints, and the application's own recovery behavior may still be necessary for a critical workload. ## Where Rex fits and where tmux remains useful Rex is a strong architectural fit for someone who wants graphical terminal interactions and persistent sessions across a small set of machines. It combines responsibilities that would otherwise be spread across a terminal application, a multiplexer, and connection configuration. tmux remains useful when broad terminal compatibility is central. It can be accessed from different terminal clients and is well suited to environments reached through existing SSH workflows. That portability matters when the developer cannot assume a particular graphical application is available. Rex's platform availability also needs careful wording. As checked on November 8, 2026, the official installation page describes beta access for the macOS application and Linux and FreeBSD servers. It distinguishes those servers from graphical clients on other platforms that are not yet part of public testing. A Linux server listing does not establish that a Linux desktop client is available. Rex's prerelease positioning has included closed-source distribution and an unsettled business model. That is not a basis for promising stable pricing, permanent availability, or a particular production-support commitment. The current beta status is a concrete limitation to evaluate alongside features. Nor is a terminal workspace automatically an agent orchestration system. Displaying several sessions does not assign ownership of shared files, resolve Git conflicts, or decide when changes should be accepted. Those remain project and workflow responsibilities. ## Final thoughts Rex makes a familiar persistence model part of a graphical terminal experience. It separates the client displaying a session from the server owning its programs, and can use that distinction to keep remote work available across client disconnects. **The most important question is where the program actually runs.** A MacBook can sleep while a Mac mini continues a task, but a locally hosted agent does not gain that benefit merely because its terminal is persistent. **Rex's value is the integration of session continuity, remote access, and terminal interaction.** tmux remains a practical alternative where terminal portability and existing server workflows matter more. Either approach still needs appropriate access control, an active execution host, and independent validation of the work performed inside the session.