Troubleshooting

Most failures here have exactly one cause and one fix. The list is ordered the way problems actually arrive.

Your Mac isn't in the list

The client asks the relay which Macs are yours, so a Mac appears once it has dialled out and stayed connected. Work down the list:

1. You are signed in here, on the same Marginal Utility account the Mac is signed into. A signed-out browser is shown a sign-in link rather than an empty list.

2. Remote control is not set to Off in Settings → Remote control. Off means the Mac never dials out, so there is nothing for the relay to introduce.

3. The Mac is awake and online. Settings → Remote control shows the link's real state — connecting, a named failure, or reachable — rather than just repeating the setting back at you.

4. The Mac is signed in. A signed-out Mac has no account to be found under, and every pairing against it is refused macSignedOut.

The pairing code is refused

• Wrong or stale code. Codes are single-use and lapse a few minutes after they appear. Take a fresh one from the pane.

• Different accounts. The device and the Mac have to be on the same account — that is the whole gate. The refusal says which end to fix.

• “Wait a moment”. The account backend didn't answer, or too many attempts arrived at once. That reads as wait rather than no, deliberately: an outage must not look like a mismatch. Try again shortly.

Your Mac fell asleep

A sleeping Mac holds no connection, and nothing here can wake it — your Mac dials out to reach the relay, so there is no door to knock on. This is the one dead end that waiting doesn't clear.

Saggar holds the Mac off idle sleep while a paired device might need it, which is on by default while the Mac is plugged in. Settings → Remote control says whether it is actually holding, and why not when it isn't — nothing paired yet, running on battery, or the setting turned off. Worth a glance before you leave the house rather than after.

What the hold can't cover: closing the lid sleeps the Mac whatever any app asks for, and so does the Apple menu's Sleep. The display going dark on its own is fine — that isn't sleep, and your terminals stay reachable through it.

Nothing works, from anywhere

There is no offline path. Your Mac is reached through the relay, so no internet at either end — or a relay outage — means no remote control at all, even with the phone and the Mac on the same Wi-Fi. It is the one cost of never opening a port.

It paired, then bounced back to the pairing screen

A 401 anywhere means the grant is gone — revoked on the Mac, or expired. The client clears it deliberately rather than showing a live-looking page that refuses every action. Pair again.

The header dot has gone grey

No heartbeat has arrived recently. Usually the Mac is asleep, or this device has lost its connection. A banner says how old the state on screen is, so a plausible-looking fleet can't be mistaken for a live one, and its Reconnect button rebuilds the stream without a reload. The stream also retries on its own with a widening backoff.

A phone that woke up showing yesterday's state

iOS suspends the live stream the moment the tab is backgrounded or the phone locks, and the connection often comes back dead without saying so. Bringing the client to the front rebuilds it and refetches, so the wait is a moment rather than the backoff's. If it still looks stale, the banner's Reconnect button forces the same thing.

For the state to arrive while the page is closed at all, you want the bell — see alerts.

The bell isn't there

Web push needs a service worker, and a service worker needs the browser to support one on this page. On iOS that means installing the page to the home screen first — Safari offers push only to an installed app. More on alerts.

Actions are missing or greyed out

The tier is doing its job. View can act on nothing and approve cannot type arbitrary text. An armed Mac grants drive, so this is usually an older grant kept at the tier it was given — unpair and pair again. The tier a device holds is shown in the header.

Still stuck

The Settings pane keeps an audit log of what was asked and what was answered, which is usually the fastest way to see whether a request arrived at all.