Amp Runner Desktop: Trying the App Amp Built From the Thread

I run the desktop side of the Amp runner on my Apple Mac mini. Beyond cloud sessions, this means the Mac mini at home can take on extra builds, lint checks and similar tiring processes instead of sitting idle.

That is my impression from ongoing use rather than a measured test, and I did not record the dates or the workloads. The rest of this note describes what Amp documents.

What changed

Amp's news post of October 16, 2026 says you can now see and control your macOS or Linux runner's desktop, and names trying native apps that Amp builds, such as iOS apps, as the main use. In the macOS app the switch is Share This Mac's Display under the runner settings; from the CLI, the runner is started with amp --no-tui --desktop.

The runner documentation adds that threads get a Desktop tab in any browser and in the Amp iPhone and iPad apps. Besides trying a fresh build, it mentions clicking through a dialog that is holding up a thread, and watching Amp drive a native app before taking over.

How the connection works

On macOS, threads see and control the Mac's own display, and a helper app asks for Screen Recording and Accessibility permissions. On Linux, the runner starts its own headless virtual desktop at 1280x720, so the user's own screen stays untouched and no permission prompt is needed.

The Desktop and Terminal tabs connect over WebRTC, directly when the networks allow it or through a TURN relay, and fall back to Amp's relay if neither connects within five seconds. Amp's post says the view is nearly instant when the runner is on the local network or nearby.

This builds on the earlier Amp Orbs Field Note. Orbs are machines Amp creates for each thread, while a runner is a machine you already own. Amp's documentation says portals are available only on orbs, so desktop sharing gives runners a visual view of their own.

My runner is a Mac mini, so the macOS behaviour described above is the relevant one for me. This note makes no claim about how responsive the Desktop tab feels, because I did not time it.

Limits worth knowing

On macOS, desktop sharing needs an Apple Silicon Mac on macOS 26 or later running the arm64 Amp CLI. On Linux, the runner needs labwc, wlr-randr and ffmpeg, and sharing an existing GNOME, KDE or X11 session is not yet supported. The documentation also warns that anyone who can write to a thread on the runner can see and control its desktop, which matters on a shared runner.

Where I would draw the line

For me, the main value is that a machine I already own does useful work: next to cloud sessions, the Mac mini at home handles extra builds, lint checks and other tiring processes instead of sitting idle. I have not compared this with an orb on cost or speed, so I would not draw a firm line between the two from this use.

A useful next test would record the runner's operating system and hardware, the network path, the app being tested, and whether the session stayed usable through a full build-and-try loop.