Superlogical is building Rex, a terminal multiplexer that makes persistent sessions the starting point for development work. If Ghostty made you reconsider how a terminal should feel, Rex raises the next question: how should the work inside that terminal be organized, controlled, and carried between devices?
For developers, the interesting change is that a session can become something both a person and a program return to: a place containing an agent, its tests, a running service, and the context needed to continue. For mobile coding, that leads to a familiar goal: keep the work in place while the person changes devices.
Research checked November 4, 2026. Product availability below follows the current installation documentation; the October launch announcement describes an earlier testing scope. This is a documentation-based overview, not a hands-on review.
What is Superlogical building?
The company introduction proposes a durable session connecting work that is usually scattered between terminals, jobs, and operational tools. Its stated sequence is to build a strong multiplexer, make its contents composable, and eventually make that system suitable for production operations.
The following illustration represents that organizing idea, rather than a diagram of implemented Rex internals:
Consider an ordinary agent task: the agent edits a repository, a test suite runs elsewhere, and a preview service remains open while you review a change. Today, reconnecting often means recovering those pieces separately. A session-oriented design raises a better question: can the related work remain discoverable as one context?
Our interpretation is that the session becomes an object you return to, rather than a temporary view that disappears when a window closes. That is especially relevant to short phone check-ins, where finding the right task can take longer than answering its question.
How Ghostty fits into the picture
The Ghostty connection is useful context. In his announcement, Mitchell Hashimoto explains that Superlogical builds on the public, MIT-licensed libghostty components. Ghostty continues as a nonprofit project with its own governance and roadmap.
That gives Rex an established terminal foundation while leaving it room to explore session management and remote work. Rendering a terminal well and keeping an entire working context available are related engineering problems. Rex is interesting because it brings those concerns into one product experience.
What is Rex, and what is available now?
The October 5 public-testing announcement introduced Rex by name. It described persistent sessions, remote connections, and program activity status, with invitations initially limited to the macOS app.
The current installation page now lists a broader server scope:
| Component | Published testing availability when checked |
|---|---|
| macOS application | Available to testers, with an included local server |
| Linux server | Available to testers; server only |
| FreeBSD server | Available to testers; server only |
| iOS, Linux, and Windows clients | Described as in development and outside the current testing scope |
| Windows server | Described as running internally, outside the current testing scope |
Access follows the beta invitation and tester-download path. For developers planning a cross-device workflow, the installation page is the place to follow each client's rollout.
The same October announcement says Rex clients and servers will be free, require no account for use, and support self-hosting. It also says the broader commercialization plan has not been disclosed. Those are published commitments about Rex, not evidence that every future Superlogical service will be free or that the whole product has an open-source license.
What changes for developers?
The terminal is a useful starting point because people, agents, test runners, and services already meet there. The bigger opportunity is to make their relationships easier to preserve and operate. Our reading of Rex's documentation and Superlogical's roadmap suggests four changes worth watching.
1. The session becomes the thing you return to
Today a developer often remembers work by its window position: the left pane has the agent, the second tab has tests, and another terminal has the server. That memory becomes fragile when you leave the desk or juggle several repositories.
Rex's object model organizes work into sessions, windows, blocks, and connected clients. Objects have stable IDs as well as human-readable labels. A session can represent a project, with its related terminals arranged inside it.
The practical benefit is a more dependable return path. Instead of reconstructing which window belonged to a task, you can return to the identified working context. On a phone, this matters because every extra navigation step takes a larger share of a short visit.
2. Agents can operate the workspace through explicit interfaces
A coding agent often needs to do more than edit a file. It may need a second terminal for tests, a log stream beside the implementation, or a way to inspect a service without interrupting its own conversation.
Rex's agent guide describes teaching agents its workspace operations through a skill. The Server API can describe its available methods and schemas from the connected server itself. That gives an agent or script a way to discover what it can actually call on that version.
The change is practical: “open a test terminal for this task” can refer to an addressable workspace operation, rather than a sequence of mouse positions. The human can continue to inspect the resulting terminal. Whether that feels reliable depends on target selection, clear scope, and the ability to see what the agent created.
3. Remote development becomes part of the session experience
Keeping work on another machine is familiar. The difficult part is making remote work feel consistent: find the right host, identify the right task, recover from a network interruption, and preserve enough context to continue.
Rex is putting a native client and its session server into one experience. Its remote-access documentation describes server listeners and Tailscale-based access. That makes connection identity and reachability part of the product's remote workflow, alongside terminal persistence.
For a developer, the useful question is whether moving between local and remote work reduces setup and rediscovery. The code and tools still run where the server is, so an always-on development host remains valuable when a laptop is asleep. The client can make returning to that host easier.
4. Terminal work could become more composable
Superlogical's published plan goes beyond keeping terminals alive. It describes making the contents of a session composable and eventually suitable for production operations. That is a direction to follow as the product develops.
Imagine a session where an implementation agent, a build result, a preview, and the relevant operational history remain associated with the same task. The developer spends less effort carrying context between unrelated tools. For teams, the same idea could improve handoffs: another person arrives at the working context instead of receiving several disconnected terminal excerpts.
The important evaluation is how much of that context is actually preserved and addressable in each release. A persistent terminal is a concrete foundation; richer task relationships, collaboration controls, and production workflows are capabilities to assess as they arrive.
Activity status: why OSC 7501 matters
Rex publishes the Program Status Protocol, OSC 7501. A program can report whether it is working, idle, blocked, finished, or failed. The protocol describes the state; the terminal chooses how to present it.
This solves a particular attention problem. A long-running command can be alive and still need a person. Merely preserving its process does not tell you that it has reached a question.
The documentation distinguishes present features, such as session and tab indicators, from future ideas such as mobile push notifications. It also calls OSC 7501 a generic terminal protocol. herdr-core uses it too, but common status reports do not make the runtimes or their clients interchangeable.
For a phone workflow, our practical test would be whether a reported state leads you to the exact task and its real prompt quickly enough to make a careful decision. A green or blocked badge by itself is not the whole interaction.
For example, a test run that has finished and an agent waiting for approval both deserve attention, but they need different actions. Explicit status can help a client distinguish “read this result” from “answer this question.” As support spreads to more programs and clients, the terminal can become a clearer queue of work requiring a decision.
What is worth following as Rex develops?
A good way to track a new tool is to follow a handful of observable improvements in your own workflow:
| Area to follow | Why it matters to a developer | A useful evaluation question |
|---|---|---|
| Session continuity | Leaving a device should preserve the working context | Can I find the same task, output, and directory when I return? |
| Program status adoption | A running process may be waiting for me | Do my actual agents and tools distinguish working, blocked, and finished? |
| CLI and API evolution | Automation needs dependable targets and results | Can a script use stable object IDs and discover the connected server's methods? |
| Remote access and identity | Session control also controls real host-side work | Is the connection model clear for my personal machine or shared environment? |
| Native client rollout | Different devices need different reading and input experiences | Does the client make navigation, selection, scrolling, and replying comfortable? |
| Collaboration and history | Related work should be understandable to the next person | What context can another developer recover, and which controls govern access? |
Most of these are easier to assess with one real repository than with a large demo. Start an agent, run a test, leave the client, return, and review the result. Then try an interrupted connection and a task that asks a question. Note how much context you had to reconstruct manually.
If you already have beta access, these documented read-oriented commands offer a compact way to inspect the model from inside a Rex terminal:
rex ls --json
rex session inspect
rex block inspect
rex api list
rex api describe session.view
The CLI guide explains command context and target selection; the API guide explains discovery. This is also a useful distinction for anyone writing tooling: a friendly label helps a person navigate, while a stable ID helps automation return to the intended object.
Superlogical, tmux, Herdr, and Redock solve different parts
These names are easier to compare by the decision each one asks you to make:
| Tool or project | The decision to evaluate |
|---|---|
| Ghostty | Which terminal application and rendering experience do I want? |
| tmux | How will I keep host-side terminal sessions and panes persistent? |
| Herdr TUI | How will I organize terminal agents across project workspaces? |
| herdr-core | Which programmable terminal runtime will own the work? |
| Rex | Do I want Superlogical's integrated client/server session model? |
| Redock | How will I return to my development host and project from a phone? |
This is a workflow framing, not a feature-equivalence table. A product can occupy several layers, and the right combination depends on where your existing work lives. The Shell, SSH, and tmux guide explains the distinction between reaching a machine and preserving a task on it.
What this means for mobile coding today
The appeal of device continuity is that a desktop and a phone can become access points to the work, rather than separate places where you must recreate it. The conceptual handoff looks like this:
The immediate opportunity for mobile coding is a shorter loop between a task needing attention and a person responding. A useful mobile session can be brief: identify the task, read what changed, answer one question, and leave the host working. Client rollout and native interaction quality will determine how comfortable that loop becomes in Rex.
In Redock, save the development Host, bind a Project to its repository, and use the documented tmux or Herdr TUI persistence path for the agent terminal. Keep repeated Git, test, build, and log commands as Actions so a short visit can leave a result you can find again. The Redock setup guide walks through that structure.
Redock is actively researching and following Superlogical and Rex, and will pursue integration when the timing is right. We are particularly interested in persistent-session access, program status, remote interfaces, and the experience of returning to an agent from a phone. The goal is to make those capabilities useful within a coherent mobile workflow as the platform develops.
For developers following the same direction, the most valuable change may be continuity: the work keeps an identity and context while people, agents, and devices take turns interacting with it. Rex is worth watching for how well it turns that idea into everyday operations—finding a task, understanding its state, and continuing with less preparation.
FAQ
What is Superlogical?
Superlogical is a developer-tools company building Rex, a terminal multiplexer, as the starting point for a broader session-based model of software work.
Is Superlogical the same as Ghostty?
No. Superlogical is a separate company. Hashimoto says it builds on public libghostty components while Ghostty keeps its nonprofit governance and roadmap.
Can I use Rex on an iPhone today?
The installation documentation checked for this article says the iOS client is not in the current testing scope. It lists the macOS app and Linux/FreeBSD servers for testers. Check that page for changes.
How is Redock following Superlogical and Rex?
Redock is actively researching and following their development, particularly session persistence, program status, remote access, and mobile interaction. We will pursue integration when the timing is right, with the aim of making these capabilities useful in the Redock workflow.
Sources and further reading
- Superlogical: product vision and roadmap
- Mitchell Hashimoto: announcing Superlogical
- Rex public testing begins, October 5, 2026
- Rex installation and current platform availability
- Rex CLI
- Rex agent workflows
- Rex Server API and discovery
- Rex remote-access model
- Program Status Protocol, OSC 7501
- Herdr TUI vs herdr-core
- Remote AI Coding Stack