Your terminals keep running.
A terminal workbench for developers and coding agents. Shells run on your laptop or a server and keep going when you close the window; the diff, the commits and the deploy open beside them.
Built for work that outlives the window.
Available
Shells outlive the window
Close the app, lose the Wi-Fi, switch devices. The session is still running on its host when you come back.
Start the test suite, close the window, come back an hour later: the run is as far as it got, its output all there.
Persistent sessionsAvailable
Local and remote, one workbench
Your laptop and your servers side by side, over Tailscale SSH or the SSH you already use.
A build server's sessions in one tab, your laptop's in the next, both with the same blocks.
Remote hostsAvailable
Agents get a workbench
Run Claude Code where the code lives. It opens its own splits and pages, and you review its work in the blocks beside it.
Claude Code opens its dev server, its tests and its diff in blocks beside itself, so you see what it did.
Claude CodeOne change, seen by every block.
A block is a view that opens beside the terminal doing the work. In this recording a fraud check is added to a made-up order service, and three blocks follow it:
- Changes
- The edit as a diff, live, with a hunk ready to stage.
- Workflows
- The Temporal workflow drawn from its Go source, with the new step in it.
- History
- The commit graph. The commit made in the shell arrives on top of it.
Close the window. Come back to the progress.
Terminals run on their host, not in the window. Closing the app ends nothing on the host; opening it again shows each terminal as it is now.
Start a task
Ask Claude Code to fix a bug and hand the new tests to a second agent in its own tab.
Close the window
Quit the app, or lose the connection. Both agents keep running on the host.
Reconnect
Open the app again. The second agent has finished, its output in its terminal.
Two tests fail: the discount is added, not taken off.
Fixing pricing.ts, then handing more tests to a second agent.
Nothing on screen.
On the host, both agents are still running.
The window opens on the same tabs.
The second agent has finished.
How fast it comes back
Medians of 5 runs of Ubik's own benchmarks, each in a fresh process, on a Linux workstation pinned to 8 cores. Host and app on the same machine unless a figure says otherwise. Your hardware, network and programs change the numbers.
Reconnecting
- 64 terminals back on screen
- 19.8ms
- Each with 10,000 rows of output, same machine.
- 64 terminals' screens over a network
- 173ms
- 100 Mbit/s, 20 ms round trip. At 80 ms: 622 ms.
- 16 terminals' screens in a browser
- 9.5ms
- Through the host's gateway over WebSocket. WebTransport: 2.4 ms.
Every result, beside its terminal.
The official extensions add a block each, and come with the app: the diff, the commit graph, the file, the workflow, the deployment, the infrastructure. ⇧⌘T adds one.
Recorded in the workbench on made-up projects. Keys as on a Mac.
Also in the workbench
Start on this machine.
The desktop app includes a local host, and local sessions need no account. The guide goes from installing to your first session, your first block, and reconnecting.
Questions before you install.
What happens when my laptop sleeps or I close the app?
Shells run on a terminal host, not in the window. Closing the app, the browser tab or the laptop's lid leaves a remote host's shells and agents running; reopen any client and each session is where the work got to.
When the host is the laptop itself, its shells pause while it sleeps and carry on when it wakes.
Leave and come backWhat if the host restarts?
Updating a host replaces it with the new build in place: the same shells keep running, with their screens and history.
If the machine reboots or the host crashes, running shells end. The host brings back each session's layout and folders with new shells, resumes a Claude Code conversation, opens Codex's resume list, and keeps the output of finished blocks to read.
A host the app installed on a Linux server starts again after a reboot where the server runs systemd user services.
What needs an account?
Nothing on your own computer: the desktop app and its sessions work without signing in, and you can add a remote host over SSH.
An account keeps your remote hosts on every desktop app signed in to it, opens them from the browser workbench, and connects a Git provider once for all your devices.
See the planWhere does my code live?
On your hosts: the computer you work on and the machines you add. Files, shells and running programs stay there; the apps show what the host sends them.
Ubiklabs' servers keep your account and, for each remote host, its name, address and public certificate. They never store a key that opens a host. If you connect a Git provider, only an encrypted refresh token is kept, and each device gets access that lasts a few hours.
What does remote access need?
A Linux computer, x86_64 or ARM64, that you can already reach with an SSH key or Tailscale SSH. Nothing has to be installed on it first, and it needs no internet access.
The app uses SSH once to install and start the host, then connects to it directly over QUIC, so a UDP port on the address you reached must be open to your computer. Tailscale is optional.
Add a remote Linux host