Drive a Session from your phone — and still press buy yourself.
What it's for
Remote checkout lets your own phone drive one Session on this machine while you're away from the desk — load a checkout link, tap a field, type your CVV, and press buy, all from the phone. It is the remote-desktop version of your own mouse and keyboard: the phone sends taps and keystrokes by coordinate, and Umbra decides nothing. It is off by default, and before a phone can drive anything you pair it once at the desk — the two gates a phone has to pass.
Pair your phone
Remote checkout rides the same connection as the Decision board, so the relay has to be up first. Pairing happens once, in person, before you leave the desk — because that's the whole point: the phone drives from away, so it can't scan the desktop later.
Connect the relay
Connect the Decision relay on the Team pane. Remote checkout uses the same socket — no separate endpoint.
Switch on Remote control
Flip the Remote control toggle on. It's off by default; this per-install switch is your opt-in. Turn it off and the desktop stops accepting input on the very next event.
Scan the pairing code
The desktop shows a QR code. On your phone, open umbrabrowser.com/remote (signed in on this licence) and scan it. The code carries the encryption key and the relay details straight into the phone, screen-to-camera — it never goes through the relay.
Open an Account from your phone
Once the phone is paired and connected, it lists the desktop's Accounts. Pick one, paste a link, and press Open: the desktop opens that Account exactly as its own Open button would — on its own connection, signed in as it is there — loads the link, and your phone switches to it. Sessions that are already open are listed underneath; pick one to carry on in it.
You aim it; Umbra decides nothing
This is the line to read twice. Remote input carries your taps and keystrokes and dispatches them into the Session exactly as a mouse and keyboard would. It does no label-matching, no commit-finding, and makes no Umbra decision — it cannot "find the buy button." The person on the phone aims every tap.
End-to-end encrypted to your paired phone
The relay is a rendezvous — a team may share one, or we host it — so it is never trusted with what crosses it. Pairing hands your desktop and your phone a shared key that nothing else holds, and everything on the wire is sealed with it.
Two gates, checked on both sides
The opt-in isn't trusted from one place. The renderer refuses input the moment the toggle is off, and main enforces the same opt-in independently — so neither a stale renderer nor a forged message can drive a machine whose operator switched it off.
Opt-in, twice
The toggle is checked in the renderer at fire time and re-checked in main before anything dispatches — main captures no frame and accepts no input while it's off.
Opens under your key, or drops
Inbound input is decrypted with the pairing key; a message that doesn't open is dropped before it's ever parsed.
Re-validated in main
Even after it opens, every event is untrusted. Main re-parses and clamps it, and derives the target from the validated event, so a caller can't aim an event at a Session you didn't pick.
Only what you're watching
Input is dropped unless it targets a Session with a live frame stream to that controller — you can only drive what you can see.
Links stay on the Account's connection
A link you send loads only while that tab is still on its Account's own connection. If the tab was moved to another exit or to Direct on the desktop, the link is refused and the phone says why — open the Account from the phone to load it on its own connection.
What crosses the wire
The channel is deliberately small, and sealed: a picture out, clamped input back — the relay sees only ciphertext.
Frames → phone
A scaled JPEG of the Session in front of you, a few times a second — sealed with your key. Enough to read a page, find a field, and watch a cart timer.
Input → host
Taps, scrolls, typed text, a short list of named keys (Enter, Backspace, the arrows), and navigate — each one sealed, then re-clamped on arrival. A navigate accepts only http/https links — never javascript:, data:, or a file path.
Fresh, not replayed
Each sealed input carries a timestamp; one dated more than about thirty seconds from now is refused, so a captured blob can't be replayed later.
It can't run away with your desktop
A phone that dies mid-checkout — backgrounded, out of signal, killed — must not leave the desktop capturing into the void. It can't.
If the relay restarts, or you leave the browser to copy a code, the desktop and your phone reconnect on their own and the phone comes back to the Session you were driving.
Staying reachable
While Remote control is on, the desktop keeps itself within reach of your phone: it reconnects to the relay when Umbra starts and keeps trying until the relay answers, the computer does not fall asleep on its own, and the picture keeps its pace when Umbra's window is minimised or behind others. The screen can still sleep and lock. Switch Remote control off and all of that stops.
When the phone says something is wrong
Remote control is turned off on the desktop
Switch it on in Settings → Team on the desktop.
That tab is no longer on its Account's connection
The tab was moved off its Account's connection on the desktop. Open the Account from your phone instead.
That Account did not open
The desktop says why — usually its connection no longer exists. Pick a connection for it on the desktop.
This sign-in has no active Umbra licence
Sign in on the phone with the account that holds your licence.
Couldn't reach the relay
The relay address in the pairing is wrong, or the relay is down.
You're driving your own isolated Session
Handing the controls to your phone doesn't spin up a fresh, unsealed context — it drives one of your Accounts, opened the same way as at the desk, which keeps everything that made it safe.
The honest limit
One thing remote checkout does not do, and no remote-control protocol can.